Repository navigation
Async closure argument inference is broken with functions taking FnOnce() -> futures::TryFuture #127781
Description
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 of for_each, when closure is expected to return Result:
#![feature(async_closure)]
use anyhow::Error;
use futures::{stream::repeat_with, StreamExt, TryStreamExt};
fn accept_str(_: &str) {}
fn accept_string(_: &String) {}
#[tokio::main(flavor = "current_thread")]
async fn main() -> Result<(), Error> {
repeat_with(|| "foo".to_owned())
.take(1)
.map(Result::<_, Error>::Ok)
.try_for_each(async move |value| {
// error on whole closure, rust thinks that type of value is `str`
accept_str(&value);
// type annotations needed, cannot infer type
accept_str(value.as_str());
// this works
accept_string(&value); // ok
Ok(())
})
.await?;
Ok(())
}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
rustc 1.81.0-nightly (d9284afea 2024-07-14)
binary: rustc
commit-hash: d9284afea99e0969a0e692b9e9fd61ea4ba21366
commit-date: 2024-07-14
host: x86_64-pc-windows-msvc
release: 1.81.0-nightly
LLVM version: 18.1.7
Activity
compiler-errors commentedon Jul 15, 2024
This is because the signature of
try_for_eachis:We only extract an async closure bound from cases where there is
Future<Output = ???>bound on the trait, whichTryFutureis not. There isn't even a supertrait bound that constrains the output type.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
Firstly, this would break if another blanket implementation for
TryFuturewere ever added. ↩Secondly, the combinator shouldn't really be using
FnMutbounds either -- it should be usingasync FnMutbounds. ↩compiler-errors commentedon Jul 15, 2024
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.
[-]Async closure argument inference is broken with closures returning Result[/-][+]Async closure argument inference is broken with functions taking `futures::TryFuture`[/+]10 remaining items
[unstable-rust] Use `async_closure` syntax.
[unstable-rust] Use `async_closure` syntax.
[unstable-rust] Use `async_closure` syntax.
[unstable-rust] Use `feature(async_closure)`.
[unstable-rust] Use `feature(async_closure)`.
[unstable-rust] Use `feature(async_closure)`.
[unstable-rust] Use `feature(async_closure)`.
[unstable-rust] Use `feature(async_closure)`.
Rust 1.85: Use async closure syntax.
Rust 1.85: Use async closure syntax.
Rust 1.85: Use async closure syntax.
Rust 1.85: Use async closure syntax.
Rust 1.85: Use async closure syntax.
Rust 1.85: Use async closure syntax.
Rust 1.85: Use async closure syntax.