Skip to content

Allow Future.then callbacks to be nullary #22241

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

Closed
DartBot opened this issue Feb 2, 2015 · 7 comments
Closed

Allow Future.then callbacks to be nullary #22241

DartBot opened this issue Feb 2, 2015 · 7 comments
Labels
area-core-library SDK core library issues (core, async, ...); use area-vm or area-web for platform specific libraries. library-async type-enhancement A request for a change that isn't a bug

Comments

@DartBot
Copy link

DartBot commented Feb 2, 2015

This issue was originally filed by @seaneagan


Instead of:

  action().then((_) => handleCompletion());

I want to do:

  action().then(handleCompletion);

Future.then would just need to do an is check on the arity. It could be a separate e.g. then0 method, but that would not be quite as nice UX.

@DartBot
Copy link
Author

DartBot commented Feb 3, 2015

This comment was originally written by [email protected]


Same would be nice for Future.then.onError, Future.catchError and Stream.listen callbacks.

Also, type safety can be retained if issue #4938 is fixed.

And if issue #10811 is addressed, then the arity check(s) can be avoided.

@lrhn
Copy link
Member

lrhn commented Feb 4, 2015

Not a new request, but I'm not sure that function type checks are not cheap enough that we want to put them into every future.then call.


Added Library-Async, Area-Library, Triaged labels.

@lrhn
Copy link
Member

lrhn commented Feb 4, 2015

It's also a problem that the type annotation on the argument would then have to be "Function", which is less descriptive than "action(T value)".

@DartBot
Copy link
Author

DartBot commented Feb 4, 2015

This comment was originally written by @Emasoft


action(T value) is much better and easier to type check for the analyzer, leading to less bugs. Of course is the best choice.

@rakudrama
Copy link
Member

What does it feel like to define handleCompletion with an unused optional positional parameter?

handleCompletion([_]) {
  ...
}

@DartBot
Copy link
Author

DartBot commented Feb 4, 2015

This comment was originally written by @seaneagan


@2: The function type checks would not be needed if issue #10811 were addressed by providing a primitive to call a function ignoring extra arguments.

@3/4: The type safety issue would be solved by issue #4938 (union types) which TC 52 is apparently working on.

@5: A function with an optional parameter does likely use that parameter, so I would want such a callback to be passed the Future completion value. If it doesn't use the value, then no big deal, it will just be ignored.

I would not disagree with marking this issue as blocked on either or both of the referenced issues.

@DartBot DartBot added Type-Enhancement library-async area-core-library SDK core library issues (core, async, ...); use area-vm or area-web for platform specific libraries. labels Feb 4, 2015
@kevmoo kevmoo added type-enhancement A request for a change that isn't a bug and removed triaged labels Mar 1, 2016
@floitschG
Copy link
Contributor

Closing for now.
We won't take any immediate action.
If we get #10811 then passing in a function that takes fewer arguments automatically works.
If we get union types (#4938) then we need to go through the whole library anyway and will update accordingly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-core-library SDK core library issues (core, async, ...); use area-vm or area-web for platform specific libraries. library-async type-enhancement A request for a change that isn't a bug
Projects
None yet
Development

No branches or pull requests

5 participants