Since named arguments are distinguishable from positional ones, allowing named parameters 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, () {
...
});
_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.
It is possible.
_Set owner to @gbracha._
_Removed Priority-Unassigned label._
_Added Priority-Low, Accepted labels._
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 https://github.com/Dart-Code/Dart-Code/issues/606#issuecomment-367670436
Note that we also have dart-lang/sdk#30353 'Meta-issue for discussion of the proposal to allow named arguments everywhere'.
@escamoteur exactly what I pointed in https://github.com/flutter/flutter/issues/11609#issuecomment-351441265
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.
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 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, 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 breaking 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.
Most helpful comment
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 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:
can be rewritten as:
(Obviously the front-end can probably do much better than that, 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 breaking 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.