Allow named function arguments anywhere in the argument list

[lrhn]

Since named arguments are distinguishable from positional ones, allowing named arguments to be placed anywhere in the argument list can be done without changing calling semantics.

It is an advantage in some cases where you want to put a function argument last. Example:

expectAsync(() {
  ...
}, count: 2);

would be more readable as:

expectAsync(count: 2, () {
  ...
});

[DartBot]

This comment was originally written by @seaneagan

---

FWIW, named arguments (options/flags) generally come first in command-line interfaces, and it seems to work well there.

[gbracha]

It is possible.

---

Set owner to @gbracha.
Removed Priority-Unassigned label.
Added Priority-Low, Accepted labels.

[escamoteur]

I want to add a Flutter perspective on this:

If it would be possible to place a positional parameter last this would allow to make childand children parameters of Flutter Widget constructors positional making the widget tree was more readable. Compare:

Container(
  width: 100.0,
  child: Column(
    crossAxisAlignment: CrossAxisAlignment.center,
    children: [
      Container(
        child: Text(
          "Text1",
          style: TextStyle(color: Colors.black),
        ),
      ),
      Container(
        child: Text(
          "Text2",
          style: TextStyle(color: Colors.black),
        ),
      )
    ],
  ),
)

to

Container(
  width: 100.0,
  Column(
    crossAxisAlignment: CrossAxisAlignment.center,
    [
      Container(
        Text(
          style: TextStyle(color: Colors.black),
          "Text1",
        ),
      ),
      Container(
        Text(
          style: TextStyle(color: Colors.black),
          "Text2",
        ),
      )
    ],
  ),
)

adding @sethladd and @timsneath to this

please also see Dart-Code/Dart-Code#606 (comment)

[eernstg]

Note that we also have dart-lang/sdk#30353 'Meta-issue for discussion of the proposal to allow named arguments everywhere'.

[a14n]

@escamoteur exactly what I pointed in flutter/flutter#11609 (comment)

[escamoteur]

I know that it was discussed at several places but I think it belongs in exactly this issue. That's why I try to revive the discussion here.

[lrhn]

I haven't changed my mind on this feature, so I'm still all for it.

It's completely non-breaking - all existing functions keep working, all existing function calls keep working, and all that really changes, and only if you actually use the feature, is the order of evaluation of arguments. The syntactic change is really just syntactic sugar.

The front-end can rewrite programs using this feature into old-style programs by introducing temporary variables:

foo(x: e1, e3, y: e2, e4)

can be rewritten as:

var $tmp1;   // Should be typed with static type of e3
var $tmp2;   // Should be typed with static type of e4
T $seq<T>(_, T value) => value;
foo($seq($tmp1 = e1, e3), $seq($tmp2 = e2, e4), x: tmp1, x: tmp2);

(Obviously the front-end can probably do much better than that, using an internal let construct, but this shows that a purely syntactic rewrite is possible, which is evidence that this is a very non-intrusive change).

So, cheap to do, no breakage or complications, strictly improves expressibility. I think we should just add this feature whenever we have the resource available to do it. All that's keeping it back is higher-priority changes.