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

Don't require parens on one-parameter arrow functions #1669

Closed
gosoccerboy5 opened this issue Jun 8, 2021 · 3 comments
Closed

Don't require parens on one-parameter arrow functions #1669

gosoccerboy5 opened this issue Jun 8, 2021 · 3 comments
Labels
feature Proposed language feature that solves one or more problems

Comments

@gosoccerboy5
Copy link

gosoccerboy5 commented Jun 8, 2021

This isn't really much of an important or huge request, but in my opinion the second is slightly more easily written and read than the first:

[1, 2, 3].map((item) => item * 2);
_fetchUserOrder().then((item) => print("User ordered $item"));

vs

[1, 2, 3].map(item => item * 2);
_fetchUserOrder().then(item => print("User ordered $item"));

I believe this is important because this type of pattern is often found in Dart code, especially when manipulating Futures or Iterables. In fact, a (regex) search for \(\w+\) => within the Dart SDK on my computer showed that the single parameter arrow function was used 479 times.

Any opinions on if this would be a good or bad idea?

@gosoccerboy5 gosoccerboy5 added the feature Proposed language feature that solves one or more problems label Jun 8, 2021
@lrhn
Copy link
Member

lrhn commented Jun 8, 2021

I think it's a reasonable syntax that is unlikely to be a problem parsing.
It only works for a single untyped (but inferred) non-final parameter, but that's still a lot of cases.

@TimWhiting
Copy link

It makes the old parameter look like a destructuring of a unary tuple type which I imagine would be compatible with tuples / value type destructuring if it get added.

@gosoccerboy5
Copy link
Author

Oops, duplicate of #320.

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
Projects
None yet
Development

No branches or pull requests

3 participants