Tuple element names on the left of a deconstruction

[jcouv]

@gafter commented on Tue Nov 22 2016

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

---

@jcouv commented on Wed Nov 23 2016

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?

---

@gafter commented on Wed Nov 23 2016

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.

---

@gafter commented on Wed Nov 23 2016

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.

---

@aluanhaddad commented on Sun Nov 27 2016

@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.

---

@jcouv commented on Sun May 28 2017

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.

// 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));

---

@alrz commented on Sun May 28 2017

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

---

@jcouv commented on Sun May 28 2017

@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 ;-)