Proposal: extend tuple projection initializers to preserving element names through unnamed tuples

[DavidArno]

(This proposal is a rewording of a comment from #415)

Currently, as of v7.1, the compiler can "project" tuple names across expressions. However, this "breaks down" the moment a tuple with unnamed elements is introduced. For example, the following code won't compile:

(T1, T2) Bar<T1, T2>() => (a:default, b:default);

var x = Bar<int, int>();
var y = x.a; // Bar returns (int, int), not (int a, int b), so a cannot be accessed.

There is a use case where being able to preserve names across a tuple with unnamed elements "boundary" and that is when method chaining with methods that take a generic tuple as a parameter.

This can be explained without using a complex method chaining example with the following simple code example:

public static void Foo()
{
    (T1, T2) Bar<T1, T2>((T1, T2) value) => value;

    var tuple = (a:1, b:2);
    var newTuple = Bar(tuple);
    var a = newTuple.a; // Since we passed (a, b) in, it would be extremely useful to 
                        // get (a, b) back out again
}

As ValueTuple<T1, T2> is a struct, it isn't possible to just use Bar<T> and constrain T using generic constraints. The only current solution is to use an unconstrained T, but then the method can't be constrained to a tuple and the elements are not accessible from within Bar.

UPDATE

To give a possibly clearer example, take the following extension method for (T1, T2):

public static TR Foo<T1, T2, TR>(this (T1, T2) t, Func<(T1, T2), TR> f) => f(t);

...

(a:1, b:1).Foo(t => t.a == t.b); // doesn't compile as the compiler doesn't "project" 
                                 // a & b through the (T1, T2) type declaration

[HaloFour]

I think that this is a very dangerous assumption to make. The tuple elements are named, not arbitrary generic type arguments. The tuple type going in is not the same tuple type coming out. They are completely unrelated, and they should be completely unrelated.

The names should only survive when the generic type argument is the tuple type itself, and the compiler already supports this:

public static void Foo()
{
    T Bar<T>(T value) => value;

    var tuple = (a:1, b:2);
    var newTuple = Bar(tuple);  // T is (int a, int b)
    var a = newTuple.a; // works fine
}

[DavidArno]

@HaloFour,

The issue with your code example is that T can be anything; it's not constrained to a tuple. A possible solution would be to be able to express it like:

T Bar<T, T1, T2>(T value) where T : (T1, T2) => value;

but it's not possible to constrain on structs.

I do not follow your reasoning that "The tuple type going in is not the same tuple type coming out. They are completely unrelated, and they should be completely unrelated." If I return the tuple passed in, then it clearly is the same tuple. The element names are pure sugar and extending that sugar to work in this scenario would be extremely useful.

[HaloFour]

@DavidArno

If I return the tuple passed in, then it clearly is the same tuple.

That's an implementation detail. To the compiler the method accepts (T1, T2) and returns (T1, T2). But the compiler has no idea that they are the same tuple type and should have the same element names. Could be (T1 fizz, T2 buzz) and (T1 foo, T2 bar) for all it knows.

The element names are pure sugar and extending that sugar to work in this scenario would be extremely useful.

In some cases, sure. But in all of the other cases where those tuples just happen to have the same types and number of elements those names are not only not useful, they're misleading.

[DavidArno]

In some cases, sure. But in all of the other cases where those tuples just happen to have the same types and number of elements those names are not only not useful, they're misleading.

Could you give some examples of where this would be misleading? I'm struggling to imagine a scenario where preserving element names would be less then helpful, let alone misleading.

[HaloFour]

@DavidArno

Could you give some examples of where this would be misleading?

I'd argue that it applies to pretty much every case where the method body doesn't just return the parameter. The fact that the method does this is something that the compiler wouldn't know. You're asking for the compiler to project names across an opaque boundary.

You have another option here as well, you can declare the local function to return a tuple with element names rather than an unnamed tuple.

public static void Foo()
{
    (T1 a, T2 b) Bar<T1, T2>((T1, T2) value) => value;

    var tuple = (a:1, b:2);
    var newTuple = Bar(tuple);
    var a = newTuple.a; // works fine
}

[DavidArno]

I'd argue that it applies to pretty much every case where the method body doesn't just return the parameter.

I have updated the OP to describe a more realistic scenario where the element names being projected through that boundary would be useful, as I'd argue the opposite: it pretty much would be useful in all cases. For clarity, I've reproduced the code here:

public static TR Foo<T1, T2, TR>(this (T1, T2) t, Func<(T1, T2), TR> f) => f(t);

...

(a:1, b:1).Foo(t => t.a == t.b); // doesn't compile as the compiler doesn't "project" 
                                 // a & b through the (T1, T2) type declaration

You have another option here as well, you can declare the local function to return a tuple with element names rather than an unnamed tuple...

That really would be confusing. If I passed in (c:1, d:1), I'd get back (a:1, b:1).

[HaloFour]

@DavidArno

I don't think that's any different. What happens between the invocation of that method and the invocation of the delegate are completely opaque.

[DavidArno]

Maybe a way to make those opaque types transparent to the compiler would be your "Support generics and generic type parameters in aliases" idea:

using TupleType = (T1, T2);
...
public static TR Foo<T1, T2, TR>(this TupleType t, Func<TupleType, TR> f) => f(t);
...
(a:1, b:1).Foo(t => t.a == t.b); // All is now well as (a, b) is mapped to TupleType and 
                                 // so the element names can be safely projected

That way, it's clear to the compiler that the two references to TupleType refer to the same type and thus it can safely project the element names between them. That way there's no risk of it incorrectly projecting between two unrelated occurrences of (T1, T2).

[HaloFour]

@DavidArno

Even in that case TupleType the alias is an unnamed tuple and I don't see why the compiler would assume any differently.

Do you actually have a use case where using tuples in this manner imposes a burden? I'd think that allowing the names to flow through a single generic type argument that represents the tuple type, along with its names, would be sufficient for most cases, e.g. LINQ.

[DavidArno]

@HaloFour,

Yes, I have a specific use-case. But that's specific. If the community (which seems to be you here, as no one else has commented), cannot see a use for the more generic example I've offered:

using TupleType = (T1, T2);
...
public static TR Foo<T1, T2, TR>(this TupleType t, Func<TupleType, TR> f) => f(t);
...
(a:1, b:1).Foo(t => t.a == t.b); // this should work

Then this proposal is dead in the water until others run into the same limitation and understand why this is a limitation. So I'll close this for now.

[iam3yal]

@DavidArno I've been reading and following the issue but I can't add anything useful besides saying that I agree with what @HaloFour said above:

I think that this is a very dangerous assumption to make. The tuple elements are named, not arbitrary generic type arguments. The tuple type going in is not the same tuple type coming out. They are completely unrelated, and they should be completely unrelated.

Pretty much sums up my thoughts. :)

[DavidArno]

@eyalsk,

I get that. Where my head is at the moment, tuples are the single most important feature added to v7.0. They were enhanced by v7.1. But the inability of the language/compiler to grasp that tuple A is the same tuple as tuple B, when passed across an "opaque boundary" severely limits their use. But I accept that no one else gets that/accepts the need for that. So I've closed this issue.

Maybe in future, others will see the need. Or maybe I'll remain unique in wanting to use them this way. Time will tell.

[jnm2]

An example where I ran into this is with TaskTupleExtensions. I'd like to send (Task<T1> foo, Task<T2> bar) in and get (T1 foo, T2 bar) out.

But the more I thought about it, the less convinced I've been that it's actually a smart thing to do to use the same name. Probably always better to leave the names to the judgment of the call site.

[DavidArno]

Re-opening this as a growing number of other related requests refer to it.