Roslyn: Tuple element names on the left of a deconstruction

Created on 23 Nov 2016  路  8Comments  路  Source: dotnet/roslyn

Tuple element names are currently rejected on the left of a deconstruction assignment or deconstruction declaration. However, the tuple on the left is the result type of the deconstruction, and therefore names should be permitted. Moreover, that is a way for the programmer to ask the compiler to ensure that the names are not mixed up.

On the other hand, it isn't clear what the syntax would be if one were using a tuple designation. Perhaps

var (firstName: first, lastName: last) = GetName();

If we want to permit element names that way, we would need to modify the syntax model, which means it would have to happen _very_ soon.

@MadsTorgersen @dotnet/ldm @jcouv @VSadov @AlekseyTs FYI

Area-Language Design Feature Request Language-C# New Language Feature - Tuples

Most helpful comment

@gafter
In JavaScript, there is an analogous, useful feature that provides inline renames when destructuring objects. However what makes it useful is that object property names are both required, _and_ inferrable (e.g. by TypeScript).

Or if you're asking why not infer the names, the LDM considered that and rejected it for a number of reasons, though perhaps it is worth revisiting.

On the one hand, it could be really valuable, but on the other hand it would seem to risk turning tuples into records, but just ones with very weak guarantees and that cannot be customized.

Tuples are a lovely feature 鉂わ笍 but I don't think they form a good basis for a structural type system. It could be really bad if that sort of usage became a common pattern.

All 8 comments

What if var (first, last) = GetName() produced a (string first, string last) tuple?
You are already specifying names for the parts, so why do it twice?

For the same reason that you would invoke a method SetName(first: first, last: last) instead of SetName(first, last). In the former the compiler helps ensure that you've used the intended variable for each parameter, while in the latter you're lucky if you get it right.

Or if you're asking why not infer the names, the LDM considered that and rejected it for a number of reasons, though perhaps it is worth revisiting. Even if the names can be inferred, it should still be possible to be explicit.

@gafter
In JavaScript, there is an analogous, useful feature that provides inline renames when destructuring objects. However what makes it useful is that object property names are both required, _and_ inferrable (e.g. by TypeScript).

Or if you're asking why not infer the names, the LDM considered that and rejected it for a number of reasons, though perhaps it is worth revisiting.

On the one hand, it could be really valuable, but on the other hand it would seem to risk turning tuples into records, but just ones with very weak guarantees and that cannot be customized.

Tuples are a lovely feature 鉂わ笍 but I don't think they form a good basis for a structural type system. It could be really bad if that sort of usage became a common pattern.

Whether or not we end up allowing element names in the left-hand-side of a deconstruction, the inference of tuple names was implemented for deconstructions.
C# // tuple has element names "f1" and "f2" var tuple = ((x.f1, x?.f2) = (1, 2)); // see update below, this line is a bad example var tuple = ((x.f1, x.f2) = (1, 2));

Wait, re "x?.f2" is that possible as an lvalue? I think we have a tracking-issue for that though.

@alrz :-s I picked a bad example. You're correct that x?.f2 as an L-value produces an error (cannot be used to deconstruct into). Thanks ;-)

Issue moved to dotnet/csharplang #1027 via ZenHub

Was this page helpful?
0 / 5 - 0 ratings