Tracking issue for #![feature(async_closure)] (RFC 2394 / RFC 3668)

[Centril]

This is a tracking issue for #![feature(async_closure)] (rust-lang/rfcs#2394).
The feature gate provides the async |...| expr closure syntax.

As with all tracking issues for the language, please file anything unrelated to implementation history, that is: bugs and design questions, as separate issues as opposed to leaving comments here. The status of the feature should also be covered by the feature gate label. Please do not ask about developments here.

Steps:

• Implement the RFC
• Accept another RFC
  • Async closures rfcs#3668
• Implement it: Rework support for async closures; allow them to return futures that borrow from the closure's captures #120361
• Adjust documentation (see instructions on rustc-guide)
• Stabilization PR (see instructions on rustc-guide)

Open questions (RFC 2394)

• Interaction between signature deduction and new solver.
  • Implement async closure signature deduction #121857

Open questions (RFC 3668)

• Which syntax should we choose for bounds?
  • Decide on bounds syntax for async closures (RFC 3668) #128129

Related

• Async closures rfcs#3668
• rustdoc: support for async Fn* trait bounds #127227
• [EXPERIMENT] Rewrite closure-of-async to async-closure #127827

[khionu]

Hi, what's the next step for this issue?

[gilescope]

@Centril am bumping into this one quite often in beta... from an ergonomics point of view it would be great to get this stable if there's no outstanding concerns / issues... - is this something we might consider putting 'on-deck', or does it need more settlement time?

[Nemo157]

Despite "Implement the RFC" being checked this feature is still largely unimplemented (other than the trivial case of async move || {} which is equivalent to move || async move {}), and as far as I'm aware also requires more design work before it can even really be implemented.

[khionu]

@rustbot modify labels to +AsyncAwait-OnDeck

Closures are a very commonly used language feature, especially in APIs like itertools. Enabling such APIs to be async has obvious benefits.

[Centril]

As @Nemo157 points out this is largely unimplemented and is entirely secondary to fixing all the outstanding bugs with the stable part of async/await that we are shipping in 1.39.0.

(Personally I think async closures should be considered holistically with other types of effect-modified closures. Moreover I think they might be largely redundant atop of the combination of closures with async blocks inside them.)

[CGQAQ]

Does this will allow ? on Result which have different Error type in the same async closure? currently, there is no way to done that, which is really frustrating

[Nemo157]

@CGQAQ do you have an example that fails now? Some quick testing in the playground makes it look like inference is able to handle at least simple cases correctly (I definitely could see it being possible that the two layers of generics with inferred outputs might cause some issues for inference, and async closures could potentially improve on that by tying those inferred outputs together somehow).

[mzedeler]

I am trying to create a helper for tests that are supposed to be run with tokios runtime, so the helper has to be async.

What I want is a function that takes a callback as parameter where the tests can executed, something like:

#[tokio::test]
async fn non_existing_resource() {
    Model::temp(async |model| {
        ...run tests with model here...
    }) // teardown happens in Model::temp()
}

Is there an obvious other way to acheive this?

[Fancyflame]

If I understand correctly, just replace async || {...} with || async {...}. It acts no differently to async fn.

[sunrosa]

So... is this implemented and usable in unstable, or not? I'm seeing it's marked as such, but comments saying otherwise. In what ways is this not implemented?

Also, what are the limitations of the LendingFn solution seen here? It seems like a solid solution, or in the very least, like something that should already exist. But because closures have to implement the trait, the compiler needs to have knowledge of it.

[kingwingfly]

If I understand correctly, just replace async || {...} with || async {...}. It acts no differently to async fn.

@Fancyflame
No, you can see this example. It seems the compiler cannot handle the lifetimes correctly without async_closure.

[Fancyflame]

@kingwingfly Yes, but it's none of the syntax's business, that is because the compiler cannot infer lifetimes inside closure when involving HRTB. And there is a feature solved this problem (I forget the name), I think async_closure just simply uses a part of it. This HRTB problem has been disturbing me for a long time.

Let's do some simplification. Whatever marks you add, the following code cannot pass the compilation.

let _ = |x: &i32| { move || *x };

[c-git]

Not sure if this is a suitable place to point to the workaround I use. But this is where the compiler points me every time I bump into this. This post pointed me in the right direction. My main takeaway is put the async on the right of || not the left and then progress becomes possible again (at least for my use cases).

Copy of code so others don't need to follow the link

async fn with_async_callback<Fut: Future<Output = i32>, F: FnOnce() -> Fut>(f: F) -> i32 {
    f().await
}

with_async_closure(|| async { 123 })

Edit

After I'd added my comment I went to re-read the posts and saw the one quoted below that already provided a solution but I didn't find it when I searched because I used the word workaround and possibly others will as well so I decided to leave it.

If I understand correctly, just replace async || {...} with || async {...}. It acts no differently to async fn.

@Fancyflame No, you can see this example. It seems the compiler cannot handle the lifetimes correctly without async_closure.