Expression trees support for tuples.

[VSadov]

We should consider supporting expressions with tuples in expression tree lambdas.

It can be done either by

1. Introducing new nodes that represent tuple creation/conversion/field accesses or
2. Use lowered form

Option 1 is more desirable since it is more expressive, but will require introducing new nodes, possibly as a reducible layer on top of the standard ET nodes.

Option 2 could run into problems where tuple conversions require temporaries and in the ET version (1.0) those are not available.
It may be possible to use member bindings to avoid this problem, but it is not completely clear if that is possible and it will require that tuple conversion lowering in a context of expression trees to be significantly different.

Option 1 seems more attractive to me at the moment.

[a-a-k]

which status on this?

[evilguest]

What is preventing this from being implemented via Option 1?
See also https://github.com/bartdesmet/ExpressionFutures/blob/master/CSharpExpressions/Microsoft.CSharp.Expressions/Microsoft/CSharp/Expressions/TupleLiteralCSharpExpression.cs

[VBAndCs]

Any news about this 4 years old proposal?

[CyrusNajmabadi]

Any news about this 4 years old proposal?

Nope. No news.

[sjd2021]

Is this being worked on?

[CyrusNajmabadi]

No. It is not being worked on. See #12897 (comment)

[jnm2]

@CyrusNajmabadi Are you sure? dotnet/csharplang#4727 links this very thread.

[qsdfplkj]

This seems to be working:

Expression<Func<int, int, object>> f = (x, y) => Tuple.Create(x, y);
Expression<Func<int, int, object>> f = (x, y) => ValueTuple.Create(x, y);

[poke]

@qsdfplkj Those are standard method invocations though. This issue proposes tuples on a language level within expression trees.

[qsdfplkj]

So using the valuetuple is a good alternative?

[evilguest]

Yes, if you want to construct a tuple within the available Expression Trees (as of C# 10). creating a tuple via a method call is a good alternative to Expression<Func<int, int, object>> f = (x, y) => (x, y); that just doesn't work.
I am frustrated, since the option #1 mentioned at the start of this thread seems to be a perfect solution.
Any existing code that would break with tuples will break with tuples, regardless of the way those are constructed. (See also npgsql/efcore.pg#2458).
A code that can process (x, y) => Tuple.Create(x, y); (or any shorthand one can sketch, like 𝜏(x, y) defined as a static method on a class imported via a using statement) would work just the same way with an expression tree that uses (x, y) => (x, y);. Especially if the new node would properly implement the .Reduce() method.
I can't imagine a scenario where a node refererncing the new tuple creation syntax would break the code that is capable of handling the Tuple.Create() syntax.