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

value-free return should be allowed in function which returns FutureOr<void> #1370

Open
srawlins opened this issue Dec 16, 2020 · 1 comment
Labels
feature Proposed language feature that solves one or more problems

Comments

@srawlins
Copy link
Member

srawlins commented Dec 16, 2020

According to the current spec, only void, dynamic and Null allow for return;. I'd like to add FutureOr<void> (and FutureOr<void>??) to this list.

Don't be alarmed, my motivation is not for users making FutureOr APIs, etc. My motivation is Future.catchError, see dart-lang/sdk#35825.

The onError parameter of Future<T>.catchError is typed as Function, because the acceptable signatures of that function cannot be expressed right now. onError can either be FutureOr<T> Function(dynamic) or FutureOr<T> Function(dynamic, StackTrace). In either case the return type is FutureOr<T>.

I think it makes sense to be able to write a Future<void>.catchError handler with return; statements (Flutter engine does it in a few places).

More generally, and out of correctness, it seems inconsistent that FutureOr<void> f() {} is legal, a function body that falls off the edge without returning a value, but FutureOr<void> f() { return; } is illegal.

Related issues: At first I thought this was an analyzer bug (dart-lang/sdk#44480); other catchError discussion at dart-lang/sdk#34144

@munificent
Copy link
Member

More generally, and out of correctness, it seems inconsistent that FutureOr<void> f() {} is legal, a function body that falls off the edge without returning a value, but FutureOr<void> f() { return; } is illegal.

+1.

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

2 participants