A way to declare reusable tuple type?

[vbilopav]

It would be great to have a language option where I could declare a custom tuple type.

For example:

public tuple MyTupleType (int, string);

or named version that would be basically the same type, just named:

public tuple MyNameTupleType (int myInt, string myString);

The reason is if I for example have a method that returns a tuple:

public (int myInt, string myString) MyMethod()
{
//...
}

And then I wrap it up in another function:

public (int myInt, string myString) MyMethodWrapper()
{
    return MyMethod();
}

I need to repeat this (int myInt, string myString) more than once, possibly many times, which is kind of tedious.

Maybe it could be done with something like type keyword where we can declare custom types or something like that.

What do you think?

I really like tuples concept because they are deconstructable, elegant, and fast. But having to repeat the same combinations with the same names is kind of suboptimal.

Thanks

[Phantonia]

I guess the named version of a tuple would be a struct. Maybe something like this:

public struct MyTupleType
{
    public int MyInt { get; }

    public string MyString { get; }

    public MyTupleType(int myInt, string myString)
    {
        MyInt = myInt;
        MyString = myString;
    }

    public void Deconstruct(out int myInt, out string myString)
    {
        (myInt, myString) = (MyInt, MyString);
    }
}

Maybe you can use source generators to generate such structs more quickly?

The point of tuples is - in my opinion - to quickly put together a collection of loosely related values. If you feel the need to name it, a struct might be better.

[vbilopav]

That's interesting, thanks.

[alrz]

for now you could use a record public record MyTupleType(int, string); and return new (integer, text).
(note these are reference types. struct records is planned, and likely is going to be implemented for vnext)

To define an alias like that without defining a new type, you need two features: primitive aliases and global aliases. afaik both are being considered for a future version.

[vbilopav]

So, if those considerations you mentioning are accepted for the next version - then this could be possible to achieve.

That's great, thanks.

This could be an argument for adopting those considerations.