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.

[srawlins]

CFE has implemented this behind an experiment flag 🎉 . I'd love analyzer to match that implementation ASAP, but I'd be much more comfortable with some spec tests.

Not that it is complex (I really can't think of any interesting cases), but spec tests can improve my confidence in analyzer and CFE implementing the same thing.

[eernstg]

Cf. https://dart-review.googlesource.com/c/sdk/+/217013.

[Cat-sushi]

Is it an experimental feature of 2.15?
I can't find a mention of this in CHANGELOG.md, so far.

[eernstg]

I would not expect it to be 2.15, but this is being clarified in the implementation issue dart-lang/sdk#47451.

[devoncarew]

@eernstg @chloestefantsova - do you have a link to the spec for this?

[eernstg]

do you have a link to the spec for this?

Not yet, it will be mentioned in #1948 when it is available.

[TimWhiting]

@Hixie
Is this syntax for flutter #1072 (comment) being considered? I imagine it wouldn't be too hard to take advantage of this new feature and make all child or children properties positional without being a breaking change by creating a dart fix.

[Hixie]

I doubt flutter would move towards making subwidgets positional, because it would force a very inconsistent API (some widgets have multiple optional children), and would remove some of the affordances that help clarify the APIs (e.g. sliver/slivers vs child/children). We've looked at doing this kind of thing many times, but while it often seems attractive at first, IMHO the complete story is never sufficiently compelling.

[leafpetersen]

This feature is now turned on by default at HEAD, and will be available without a flag in the upcoming beta. Work on downstream tooling support is still in progress.

[rrousselGit]

Going back to this @Hixie

I doubt flutter would move towards making subwidgets positional, because it would force a very inconsistent API (some widgets have multiple optional children), and would remove some of the affordances that help clarify the APIs (e.g. sliver/slivers vs child/children). We've looked at doing this kind of thing many times, but while it often seems attractive at first, IMHO the complete story is never sufficiently compelling.

I think the sliver case could be dealt with by the linter instead of a naming convention. By maybe annotating sliver widgets with a @sliver and have parameters that expect Slivers use an @expectSliver

As for widgets which have multiple children, I don't think they should be impacted.

I'd expect this syntax change to only apply to parameters currently called children or child.
Amything that uses a different name would stay as a named parameter

This would match how React handles this:

<Column>
  <Container />
</Column>

vs:

<Scaffold
  appBar={<AppBar />}
  body={<Container/>}
/>

[mit-mit]

Enabled in language version 2.17 and above