Skip to content
New issue

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

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

Already on GitHub? # to your account

Allow Future.then callbacks to be nullary #22241

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 seane...@gmail.com


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.

# for free to join this conversation on GitHub. Already have an account? # 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