Allow Future.then callbacks to be nullary

[DartBot]

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]

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]

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]

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]

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]

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

handleCompletion([_]) {
  ...
}

[DartBot]

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.