-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Async closure argument inference is broken with functions taking FnOnce() -> futures::TryFuture
#127781
Comments
This is because the signature of
We only extract an async closure bound from cases where there is I also do not expect this to ever be fixed, because that would require overly complicating the closure signature inference algorithm in ways that make me quite uncomfortable12. The correct solution is to rework the futures crate to have first-class async closure support, so for now I'd recommend just ascribing your type names. Sorry! Footnotes |
Alternatively, rust-lang/futures-rs#2763 would fix this when paired with a slight adjustment to the closure signature inference that I'd be happy to make, but it seems like that PR is blocked. |
futures::TryFuture
futures::TryFuture
FnOnce() -> futures::TryFuture
Note: This causes type inference failures, requiring us to specify the closures’ parameter types explicitly. I gather from reading issue <rust-lang/rust#127781> that this may be rectified by using native `AsyncFnOnce` / `async FnOnce` syntax, but that currently cannot specify the `+ Send + 'static` bound without also using `return_type_notation`, which is an incomplete feature.
…c-closure-inference, r=lcnr Infer async closure args from `Fn` bound even if there is no corresponding `Future` bound on return In rust-lang#127482, I implemented the functionality to infer an async closure signature when passed into a function that has `Fn` + `Future` where clauses that look like: ``` fn whatever(callback: F) where F: Fn(Arg) -> Fut, Fut: Future<Output = Out>, ``` However, rust-lang#127781 demonstrates that this is still incomplete to address the cases users care about. So let's not bail when we fail to find a `Future` bound, and try our best to just use the args from the `Fn` bound if we find it. This is *fine* since most users of closures only really care about the *argument* types for inference guidance, since we require the receiver of a `.` method call to be known in order to probe methods. When I experimented with programmatically rewriting `|| async {}` to `async || {}` in rust-lang#127827, this also seems to have fixed ~5000 regressions (probably all coming from usages `TryFuture`/`TryStream` from futures-rs): the [before](rust-lang#127827 (comment)) and [after](rust-lang#127827 (comment)) crater runs. Fixes rust-lang#127781.
Note: This causes type inference failures, requiring us to specify the closures’ parameter types explicitly. I gather from reading issue <rust-lang/rust#127781> that this may be rectified by using native `AsyncFnOnce` / `async FnOnce` syntax, but that currently cannot specify the `+ Send + 'static` bound without also using `return_type_notation`, which is an incomplete feature.
Rollup merge of rust-lang#129072 - compiler-errors:more-powerful-async-closure-inference, r=lcnr Infer async closure args from `Fn` bound even if there is no corresponding `Future` bound on return In rust-lang#127482, I implemented the functionality to infer an async closure signature when passed into a function that has `Fn` + `Future` where clauses that look like: ``` fn whatever(callback: F) where F: Fn(Arg) -> Fut, Fut: Future<Output = Out>, ``` However, rust-lang#127781 demonstrates that this is still incomplete to address the cases users care about. So let's not bail when we fail to find a `Future` bound, and try our best to just use the args from the `Fn` bound if we find it. This is *fine* since most users of closures only really care about the *argument* types for inference guidance, since we require the receiver of a `.` method call to be known in order to probe methods. When I experimented with programmatically rewriting `|| async {}` to `async || {}` in rust-lang#127827, this also seems to have fixed ~5000 regressions (probably all coming from usages `TryFuture`/`TryStream` from futures-rs): the [before](rust-lang#127827 (comment)) and [after](rust-lang#127827 (comment)) crater runs. Fixes rust-lang#127781.
Note: This causes type inference failures, requiring us to specify the closures’ parameter types explicitly. I gather from reading issue <rust-lang/rust#127781> that this may be rectified by using native `AsyncFnOnce` / `async FnOnce` syntax, but that currently cannot specify the `+ Send + 'static` bound without also using `return_type_notation`, which is an incomplete feature.
Note: This causes type inference failures, requiring us to specify the closures’ parameter types explicitly. I gather from reading issue <rust-lang/rust#127781> that this may be rectified by using native `AsyncFnOnce` / `async FnOnce` syntax, but that currently cannot specify the `+ Send + 'static` bound without also using `return_type_notation`, which is an incomplete feature.
Note: This causes type inference failures, requiring us to specify the closures’ parameter types explicitly. I gather from reading issue <rust-lang/rust#127781> that this may be rectified by using native `AsyncFnOnce` / `async FnOnce` syntax, but that currently cannot specify the `+ Send + 'static` bound without also using `return_type_notation`, which is an incomplete feature.
Note: This causes type inference failures, requiring us to specify the closures’ parameter types explicitly. I gather from reading issue <rust-lang/rust#127781> that this may be rectified by using native `AsyncFnOnce` / `async FnOnce` syntax, but that currently cannot specify the `+ Send + 'static` bound without also using `return_type_notation`, which is an incomplete feature.
Note: This causes type inference failures, requiring us to specify the closures’ parameter types explicitly. I gather from reading issue <rust-lang/rust#127781> that this may be rectified by using native `AsyncFnOnce` / `async FnOnce` syntax, but that currently cannot specify the `+ Send + 'static` bound without also using `return_type_notation`, which is an incomplete feature.
Note: This causes type inference failures, requiring us to specify the closures’ parameter types explicitly. I gather from reading issue <rust-lang/rust#127781> that this may be rectified by using native `AsyncFnOnce` / `async FnOnce` syntax, but that currently cannot specify the `+ Send + 'static` bound without also using `return_type_notation`, which is an incomplete feature.
Note: This causes type inference failures, requiring us to specify the closures’ parameter types explicitly. I gather from reading issue <rust-lang/rust#127781> that this may be rectified by using native `AsyncFnOnce` / `async FnOnce` syntax, but that currently cannot specify the `+ Send + 'static` bound without also using `return_type_notation`, which cannot yet be used upon `F: FnOnce()` bounds, as opposed to non-`Fn` trait bounds.
Note: This causes type inference failures, requiring us to specify the closures’ parameter types explicitly. I gather from reading issue <rust-lang/rust#127781> that this may be rectified by using native `AsyncFnOnce` / `async FnOnce` syntax, but that currently cannot specify the `+ Send + 'static` bound without also using `return_type_notation`, which cannot yet be used upon `F: FnOnce()` bounds, as opposed to non-`Fn` trait bounds.
Note: This causes type inference failures, requiring us to specify the closures’ parameter types explicitly. I gather from reading issue <rust-lang/rust#127781> that this may be rectified by using native `AsyncFnOnce` / `async FnOnce` syntax, but that currently cannot specify the `+ Send + 'static` bound without also using `return_type_notation`, which cannot yet be used upon `F: FnOnce()` bounds, as opposed to non-`Fn` trait bounds.
Note: This causes type inference failures, requiring us to specify the closures’ parameter types explicitly. I gather from reading issue <rust-lang/rust#127781> that this may be rectified by using native `AsyncFnOnce` / `async FnOnce` syntax, but that currently cannot specify the `+ Send + 'static` bound without also using `return_type_notation`, which cannot yet be used upon `F: FnOnce()` bounds, as opposed to non-`Fn` trait bounds.
I'm writing this as a continuation of #127425
While the problem from first message in issue seems to be fixed, there are still cases when this fails.
One of examples is when using
try_for_each
instead offor_each
, when closure is expected to returnResult
:I expected to see this happen: All options used to work in past versions of rust
Instead, this happened: Without explicit type hint it fails
Version it worked on
It most recently worked on: Not 100% sure, some explanations have been made in original issue
Version with regression
The text was updated successfully, but these errors were encountered: