Proposal: Tuple deconstruction in lambda argument list

[quinmars]

A lambda that accepts a (single) tuple as argument can only be defined with the tuple as a single argument and not by the tuples items. I’d like to see that the tuple deconstruction also works in the argument list of lambdas, as shown in the following examples:

Func<(int, int), int> f1 = (t) => t.Item1 + t.Item2; // works today
Func<(int, int), int> f2 = ((a, b)) => a + b;       // should work
Func<(int, int), int> f3 = t => t.Item1 + t.Item2;  // works today
Func<(int, int), int> f4 = (a, b) => a + b;         // would be nice

Note that in the last line the parenthesis belong to the tuple deconstruction and not the lambda argument list.

This feature would be handy for Linq or Rx method chaining:

var r = Enumerable
        .Range(1, 10)
        .Select(i => (i + 1, i * i))
        .Where((a, b) => 2 * a < b)
        .OrderBy((a, b) => b)
        .Last();

Of course the given calculation doesn’t make much sense, but I guess you get the idea. That’s why I'd like to see this feature. But to be consequent, more complex constructs would become possible:

Func<(int, int), (int, int), int> f2 = ((a, b), (c, d)) => a + b + c + d;

And probably that should also be extended to methods (and delegates):

void Do((int x, int y), string name)
{
    // use here x, y, and name
}

[DavidArno]

I agree that:

Func<(int, int), int> f2 = ((a, b)) => a + b;

should work already. This is a C# 7 bug in my view.

However, I also agree that it would be good to have implicit deconstruction of tuples to parameter lists as an added bonus, as the need to use ((x, y)) seems clunky.

[ufcpp]

IMO, this should work in the near future, but not now. This may be part of Pattern Matching in the 7.X milestone.

var t = (1, 2);

if (t is (int a, int b)) // does not work today, but will work in 7.X
{
}

switch (t)
{
    case (int a, int b): // does not work today, but will work in 7.X
        break;
}

Func<(int, int), int> f = ((a, b)) => a + b; // does not work today

[Thaina]

I would agree only on

Func<(int, int), int> f2 = ((a, b)) => a + b;

But I don't agree with implicit deconstruction. In the future might be able to do anonymous function so we should always explicit. Should always avoid ambiguous syntax

[asdfgasdfsafgsdfa]

I just stumbled about this limitation as well (the second case, but I agree with all)
I wonder why it is that way. Maybe it's that people just didn't think of it, which would be no big deal.
But I wonder if there are any real reasons.

[HaloFour]

Some of the explicitly mentioned LINQ-based examples would be ambiguous. Those LINQ methods have overloads which take delegates that accept two parameters. If you could deconstruct a tuple in the lambda parameters without a special syntax it wouldn't be possible for the compiler to disambiguate between Enumerable.Where(IEnumerable<(T1, T2)>, Func<(T1, T2), bool>) or Enumerable.Where(IEnumerable<(T1, T2)>, Func<(T1, T2), int, bool>)

[solvingj]

Great suggestion, but Kudos to @HaloFour for identifying the problem with the proposed syntax.

I see that this is kept open as a proposal, but was a new issue opened for the bug with the case below?

Func<(int, int), int> f2 = ((a, b)) => a + b;

[jcouv]

For reference, linking to LDM notes: https:/dotnet/csharplang/blob/master/meetings/2017/LDM-2017-03-15.md#deconstruction-in-lambda-parameters

[jcouv]

I want to point out the relationship of this proposal to another proposal (splatting).
There are two ways of looking at the same problem: passing a composite argument to an invocation and make its parts available as parts in the method code.

• One is splatting of tuples into arguments: calling a method with a tuple, and have the elements of the tuple splat into distinct arguments of the method. You can do this today manually by invoking M(tuple.first, tuple.second).
• The other (described by present proposal) is deconstruction in lambda parameters: when a lambda is invoked with a parameter, deconstruct that parameters into elements and use those elements in the lambda body. You can do this today manually by defining a lambda as x => { var (first, second) = x; Write(first); Write(second); }.

[Thaina]

@jcouv To have lambda be a one line return without return keyword is important at least for me

var point3s = new[] { (0,0,0),(1,1,1) }
var point2s = point3s.Select(((x,y,z)) => (x,y));

[Timwi]

This should be implemented for lambdas and methods. Thanks for writing up the proposal.

I would like to point out that the OP has incorrect/inconsistent syntax for the case of methods. OP wrote:

void Do((int x, int y), string name)
{
    // use here x, y, and name
}

However, this shouldn't compile because (int x, int y) is a valid type name, so it's missing the parameter name. The following two syntaxes should both work in order to be consistent with variable declaration syntax and pattern matching:

void Do((int x, int y) (x, y), string name) { }
void Do((int, int) (x, y), string name) { }

[jnm2]

@Timwi

it's missing the parameter name

Just curious: what would the actual parameter name end up being, for older compilers?

[Timwi]

Good point, I hadn't considered that. It's actually not just older compilers that are affected: you need to be able to use named arguments to pass a tuple-typed argument to a method with optional parameters.

My proposal here would be that the syntax could be extended to accommodate an extra parameter name, for example:

public void Method((int, int) (x, y) point) { }

but this would be optional; if such an extra parameter name is not provided, the compiler would generate one by combining the names from the deconstruction syntax. For example, (int, int) (index, count) could lead to the default parameter name of indexCount. It would then have to throw a new type of error message if another provided parameter name clashes with that.

[Thaina]

Why this feature not be championed for C# 8.0 I wonder

[jhudsoncedaron]

I have to admit I expected it to work. I typed

.Select((a, b) => { /* 4 lines of code here */ return something; })

and found out it didn't work.

[Thaina]

@jhudsoncedaron Because that was the actual syntax for normal lambda

Even this feature work it should be

.Select(((a,b)) => { /* 4 lines of code here */ return something; })

I think we should deprecate the no parentheses syntax for lambda

[gafter]

@kofifus I'm not aware of any LDM champion for this idea.

[ygoe]

I'm wondering why the double-parentheses syntax doesn't work. This bug makes using language tuples in lambda functions unusable. I can only use Item1 and Item2 which says nothing. When I try to write this code (which feels correct, based on my understanding of tuple syntax elsewhere) today, the compiler freaks out completely, giving me several errors, some duplicates, in multiple places, leaving me with no clue at all what the problem is. This should be given a higher priority. I'd rather see bugs like this fixed before anybody gets crazy stuff like non-nullable nullable reference types.

[CyrusNajmabadi]

I'm wondering why the double-parentheses syntax doesn't work.

Because it's not part of the language.

This bug makes using language tuples in lambda functions unusable

Clearly not. Lots of people use them all the time.

I can only use Item1 and Item2 which says nothing.

Not the case. You can write:

Foo(((int first, int second) t) => ... t.first ... t.second ...)

Now, this isn't wonderful. And languages like javascript/typescript make this nicer like so: Foo(([first, second]) => ... first ... second ...), allowing you to avoid naming the tuple instance.

So, it's def the case this could be nicer. But it's not the case that things are unusable.

[nblumhardt]

Not the case. You can write:
Foo(((int first, int second) t) => ... t.first ... t.second ...)

Thanks for pointing that out, @CyrusNajmabadi 👍

(Unfortunately for me it was more like: "... search the web and read Stack Overflow and GitHub tickets for half an hour, and then write: ..." 😄)

[kswoll]

The solution @CyrusNajmabadi proposed works, but if you move the naming over to where the tuple is constructed, it's quite a bit nicer (particularly if you're returning IEnumerable<TUPLE> out of a method and name the tuple values in the return type):

var r = Enumerable
    .Range(1, 10)
    .Select(i => (a: i + 1, b: i * i))
    .Where(x => 2 * x.a < x.b)
    .OrderBy(x => x.b)
    .Last()

[nblumhardt]

Thanks, @kswoll .

In my case the tuple returned generically from an API that can't give the fields meaningful names (only the consumer of the API knows what each field in the tuple represents), but the tip is appreciated!

[jhudsoncedaron]

My case was similar to nbumhardt's case. The tuple appeared in template parameter expansion.

[Thaina]

Sadly this feature was so stale

[Lonli-Lokli]

Will it be implemented in after-covid era?

[jhudsoncedaron]

After we got named ValueTuple elements I stopped caring.

[Thaina]

If anyone would champion this in the future can it moved back to issue board?

[EduardSergeev]

Another workaround is to use switch expression added to C# 8:

var r = Enumerable
    .Range(1, 10)
    .Select(i => (i + 1, i * i))
    .Where(_ => _ switch { var (a, b) => 2 * a < b })
    .OrderBy(_ => _ switch { var (a, b) => b })
    .Last();

and

Func<(int, int), int> f2 = _ => _ switch { var (a, b) => a + b };

[DavidArno]

Surely that is more clearly written as:

var r = Enumerable
    .Range(1, 10)
    .Select(i => (a:i + 1, b:i * i))
    .Where(ab => 2 * ab.a < ab.b)
    .OrderBy(ab => ab.b)
    .Last();

[alrz]

Func<(int, int), int> f2 = ((a, b)) => a + b; // should work

How about Func<(int, int), int> f2 = var (a, b) => a + b; that's what deconstruction looks like everywhere.

I would add M(out var (a, b)) to this same wishlist.

I think none of these should contribute to overload resolution or type inference though - deconstruction conversion would apply as the last step and may fail.

[alrz]

Looks like LDT has already foresaw the possibility of this usage.

The contextual keyword 'var' cannot be used as an explicit lambda return type

[333fred]

I'll be honest: I don't think we foresaw anything there. I think we just didn't want to allow the return type to be explicitly specified as var.

[garcipat]

I was looking for that. Wrote this extension to make that possible. But I would appreciate if this would be standard:

public static IEnumerable<TResult> Select<TItem1, TItem2, TResult>(this IEnumerable<(TItem1, TItem2)> source, Func<TItem1, TItem2, TResult> selector)
        {
            return source.Select(s => selector(s.Item1, s.Item2));
        }

[CyrusNajmabadi]

I will champion this.