Use (value) tuples for query translation

[gafter]

If we add Tuples (#347), we could use them in the translation of linq queries instead of anonymous types.

/cc @VSadov @jaredpar

[VSadov]

I like the idea.

[svick]

Would this apply only to delegate-based providers (like IEnumerable<T>)? Because I think doing that would be a breaking change for expression-based providers (like IQueryable<T>).

[alrz]

@svick I hope not. If expression trees going to support tuples, I think it still can be done for Expression<Func<...>> at least with a compatible API?

[svick]

@alrz I don't understand, how could you make this change backwards compatible?

For example if you have (nonsensical) query like:

from foo in fooSource
let bar = foo.Bar
select bar

Then currently the generated code is:

fooSource.Select(foo => new { foo = foo, bar = foo.Bar})
         .Select(transparentIdentifier => transparentIdentifier.bar)

With this proposal, the generated code would be:

fooSource.Select(foo => (foo: foo, bar: foo.Bar))
         .Select(transparentIdentifier => transparentIdentifier.bar)

But current LINQ providers expect the former pattern and I think it's very likely many of them wouldn't work with the latter pattern, at least not without modification.

[gafter]

I doubt we would change the way we translate to expression trees. That would not make anybody's life easier.

[svick]

@alrz I'm not saying it can't be done, I'm saying it's likely that existing providers wouldn't understand it. In other words, I'm not concerned about creating the expression tree, I'm concerned about reading it.

What I'm saying is that I expect that at least some providers expect anonymous types. And if they see something else, they will not work properly. But I have no idea how common this issue would be.

[benjamin-hodgson]

I think this is a marvellous idea. I just proposed something very similar to it in the C# language repo. It has the potential to be a big win for performance and could go some of the way to undoing LINQ's reputation for being slow.

My only bit of feedback is that it might be worth considering making this behaviour optional, perhaps using a method-level attribute as I outlined in the linked issue. (I have no opinion as to whether it should be opt-in or opt-out.) It's not always desirable to use a struct - when they are large they can be expensive to copy around. This would also simplify the question of how to implement the translation for query providers that use Expression - the behaviour can be selected in a syntax-directed (rather than type-directed) manner, just by looking at the method's attributes.