Added: C# Language Design Notes for Jun 28, 2017

[MadsTorgersen]

C# Language Design Notes for Jun 28, 2017

1. Tuple name round-tripping between C# 6.0 and C# 7.0
2. Deconstruction without ValueTuple
3. Non-trailing named arguments

Please discuss.

[Joe4evr]

you have the hassle of importing ValueTuple even when you never use a tuple - if you happen to make use of deconstruction.

And I just watched Jon Skeet's talk from NDC Oslo where he complained about this. 🤣

[DavidArno]

I'm puzzled by the "Deconstruction without ValueTuple" part, as I thought this was already done for C# 7.1. I raised the request, "Suggestion: have the compiler optimise a multiple-assignment expression bodied constructor" on the roslyn repo and it has been closed by @jcouv as "fixed" for v2.1 of roslyn.

Does that fix only avoid an unnecessary tuple for a deconstruction in a constructor? What am I missing here?

[Joe4evr]

@DavidArno Check out Skeet's talk about C# 7. Somewhere half-way he expresses his annoyance that a deconstruction requires bringing in the System.ValueTuple library package (and shipping it as a dependency), even if you never actually make a Tuple anywhere in the rest of your code.

[DavidArno]

@Joe4evr,

Yep, I get that. However, the docs around the PR fix for the issue I raised (Avoid creating "steps" in deconstruction binding and optimize output), refer to it fixing situations where ValueTuple isn't really needed for the deconstruction. Thus I'm curious as to why this was raised as still being an issue at an LDM.

[HaloFour]

@DavidArno

As far as I can tell the compiler isn't actually using ValueTuple in either of those cases, but it's still validating that it's available and probably using it during an intermediate step.

[jcouv]

Previously, during binding, we would prepare the return value for the deconstruction (that means building a tuple type, thus requiring that the ValueTuple type be available in the compilation). The return value would not end up being emitted (it is optimized away when unused). But this would still mean a compilation error if ValueTuple is missing.
The latest change is that binding now also has a notion of whether the deconstruction return value may be used. The emitted IL is unchanged, we just don't produce a diagnostic if the VT types were missing.

This was brought up with LDM, since the last time the topic was discussed, we had concluded it is ok to require ValueTuple for all deconstructions. This latest design changes that (for the better).