Language Feature: Parallel Assignment

[DartBot]

This issue was originally filed by @simonpai

---

This is a refiling of #­10267, which is duplicated with a won't fix #­75, but #­75 is wrongly judged, so I have to file this ticket again to keep this idea alive. Please either leave this ticket open, or try to rejudge #­75.

Maybe it's possible to support parallel assignment like in Ruby and Python. For example:

// return domain, port,
(String, int) parseURL(String url) { ... }

String domain;
int port;
(domain, port) = parseURL('http://dart.com:9999'); // gets domain = 'dart.com', port = 9999

or even more elegantly:

(String domain, int port) = parseURL('http://dart.com:9999');

Dart should be able to keep the all type information in compile time, so it has benefit over returning an unparametrized List. But I am not sure how many effort it takes to implement this.

This is not a must-have feature, but shall come in handy when you need it.

See discussion:
https://groups.google.com/a/dartlang.org/forum/?fromgroups=#!topic/misc/peXW6k5W3f0

[lrhn]

This is asking for tupled return values as well as parallel assignment.

A pure parallel assignment would just be
  x, y = exp1, exp2;
It is still a very useful feature to avoid boilerplate, e.g.,;
  var tmp = x;
  x = y;
  y = tmp;
becomes just
  x, y = y, x;
or something like:
  a, b = b, a % b;

The lower verbosity would fit well with Dart.

Ofcourse returning a tuple would be great too, but it's a problem that all functions in Dart must return an object, and a return tuple would not necessarily be an object. Or we would have automatic destructuring of it by parallel assignment, but then we get such beauties as:
  x, y, z = foo(), bar();
where we don't know at compile time which one of foo or bar that return a pair.
It might need to be restricted to either an equal number of comma-separated values on each side, or just one expression on the right-hand-side which will then be destructured.

---

Removed Type-Defect label.
Added Type-Enhancement, Area-Language, Triaged labels.

[DartBot]

This comment was originally written by @simonpai

---

Thanks for the clarification and help. :)

[DartBot]

This comment was originally written by greg...@gmail.com

---

It would still be nice to solve the case where there is only one expression on the RHS. I don't think the lack of static types prevents this.

Something like:

  Tuple<int,String,DateTime> foo() => new Tuple._3(1, 'bob', new DateTime.now());

  var a, b, c = foo();
  print([a, b, c]);

Note, you can already do something similar - which will also give you auto completion, and multiple return values.

  var t = foo();
  print([t.one, t.two, t.three]);

It would also be possible to add language syntax to make a function returning a tuple less verbose. Something like this, but probably with different ascii:

  <int,String,DateTime> foo() => {1, 'bob', new DateTime.now()};

[pavelgj]

Iterables are already first class (used in for-in), so could this feature be iterable unpacking?
(a, b, c) = iterable;

[DartBot]

This comment was originally written by greg...@gmail.com

---

The downside of using Iterable is you can only specify one type for all elements, so in the example above you'd have the same type for a, b and c, and lose the ability to do type inference. So no completions in the editor :(

[lrhn]

Issue #18529 has been merged into this issue.

[gbracha]

We evaluated this feature and decided not to pursue it. Please bear in mind that every piece of sugar comes with a cost.

---

Set owner to @gbracha.
Added WontFix label.

[DartBot]

This comment was originally written by rkj@google.com

---

Gilad, could you share the drawbacks? If someone in few years come along it would be good if he wouldn't have to think about this from scratch.

[gbracha]

Well, an assignment is an expression. Parsing gets hairy in some cases. What does like [a, b = foo()] mean? It currently means a list with 2 elements, one with the value of a and one with the value of b (which is set to foo()). So obviously it would be incompatible to allow interpret this as a parallel assignment. You could of course say that we need parentheses and try and figure out what is going on. But the fact is that reading such code is confusing.

Now I'm sure we could do something like this if we really tried. But we looked at it and decided we didn't want to spend our cycles there.

There is a broader point that I keep explaining to people in talks, emails, forums, bugs etc:

Every piece of sugar you introduce helps you write something in a more concise way. It also means that whoever reads the code has to know about yet another feature, and avoid any confusion with alternative (mis)readings of the code. You've increased the learning curve for everyone. And code is read much more often than it is written.

Every piece of sugar needs to be implemented by multiple compilers and tools. You may think there are boundless resources to do this, to serve the wider audience. But that is never true. The resources are always finite, and every piece of sugar comes at the expense of some other engineering work: fixing bugs (and the new feature is itself a source of bugs, both directly and due to the complexity it engenders in the code), optimizing or adding more valuable features.

Of course none of this applies to your favorite feature. Especially if you only look at your use cases, and not how it operates in general. That is why proposals that are basically just an attractive example are so suspect.