Language: Allow named function arguments anywhere in the argument list

Created on 2 Dec 2013  路  7Comments  路  Source: dart-lang/language

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, () {
   ...
 });

feature small-feature

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:

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.

All 7 comments

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

Was this page helpful?
0 / 5 - 0 ratings

Related issues

leafpetersen picture leafpetersen  路  3Comments

mit-mit picture mit-mit  路  3Comments

panthe picture panthe  路  4Comments

leonsenft picture leonsenft  路  4Comments

lrhn picture lrhn  路  4Comments