Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow named function arguments anywhere in the argument list #1072

Closed
lrhn opened this issue Dec 2, 2013 · 18 comments
Closed

Allow named function arguments anywhere in the argument list #1072

lrhn opened this issue Dec 2, 2013 · 18 comments
Assignees
Labels
feature Proposed language feature that solves one or more problems small-feature A small feature which is relatively cheap to implement.

Comments

@lrhn
Copy link
Member

lrhn commented Dec 2, 2013

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
Copy link

DartBot commented Feb 25, 2014

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
Copy link

gbracha commented Aug 27, 2014

It is possible.


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

@munificent munificent changed the title Allow named function arguments to be placed anywhere in the argument list, not just after positional ones. Allow named function arguments anywhere in the argument list Dec 15, 2016
@escamoteur
Copy link

escamoteur commented Jul 8, 2018

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
Copy link
Member

eernstg commented Jul 9, 2018

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

@a14n
Copy link

a14n commented Jul 9, 2018

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

@escamoteur
Copy link

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
Copy link
Member Author

lrhn commented Jul 9, 2018

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.

@lrhn lrhn transferred this issue from dart-lang/sdk Jul 7, 2020
@lrhn lrhn added the feature Proposed language feature that solves one or more problems label Jul 8, 2020
@lrhn lrhn added the small-feature A small feature which is relatively cheap to implement. label Jul 8, 2020
@mit-mit mit-mit added this to Being implemented in Language funnel Oct 15, 2021
@srawlins
Copy link
Member

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
Copy link
Member

eernstg commented Oct 22, 2021

@Cat-sushi
Copy link

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

@eernstg
Copy link
Member

eernstg commented Oct 25, 2021

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

@devoncarew
Copy link
Member

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

@eernstg
Copy link
Member

eernstg commented Nov 1, 2021

do you have a link to the spec for this?

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

@TimWhiting
Copy link

@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
Copy link

Hixie commented Jan 26, 2022

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
Copy link
Member

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
Copy link

rrousselGit commented Mar 6, 2022

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
Copy link
Member

mit-mit commented Apr 28, 2022

Enabled in language version 2.17 and above

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature Proposed language feature that solves one or more problems small-feature A small feature which is relatively cheap to implement.
Projects
Development

No branches or pull requests