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

[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
• Adjust documentation (see instructions on rustc-guide)
• Stabilization PR (see instructions on rustc-guide)

Unresolved questions:

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

None as of yet.

[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).

[RpxdYTX]

How async closures would be expressed as a function parameter? i feel that

fn takes_async_closure<F: Future<Output = ()>>(_:  impl Fn() -> F)

would be too verbose, something like AsyncFn, AsyncFnMut and AsyncFnOnce would be better.
Also, closures that return futures don't work well when a closure parameter is a reference.

[hamza1311]

What's the current status of this issue? According to the description, it says only the stabilization is left. How can one help push this to stabilization?

[1216892614]

If this feature stable, will both of these code work like same:

1. without feature

async fn sayer() {
    let mut hs = Vec::new();
    for n in (0..5).rev() {
        hs.push(tokio::spawn(sleep_n(n)));
    }
    for h in hs {
        h.await.unwrap();
    }
}

2. with feature

async fn sayer() {
    let mut hs = Vec::new();
    for n in (0..5).rev() {
        hs.push(tokio::spawn(sleep_n(n)));
    }
    let _ = hs.into_iter().map(async |i|  i.await.unwrap());
}

[peepo5]

How async closures would be expressed as a function parameter? i feel that

fn takes_async_closure<F: Future<Output = ()>>(_:  impl Fn() -> F)

would be too verbose, something like AsyncFn, AsyncFnMut and AsyncFnOnce would be better. Also, closures that return futures don't work well when a closure parameter is a reference.

Except from these potential keywords being added for convenience, is there any reason to not add async closures?

[target-san]

Aren't async closures just like normal closures but without the redundant move keyword? As in:

move | _ | async move { /* ... */}

vs

async move | _ | { /* ... */ } 

is there any other difference other than this?

The first thing is a closure which returns parameterless async block.
The second one is the actual async closure.

[IndigoLily]

As @Nemo157 said in their comment

Despite "Implement the RFC" being checked this feature is still largely unimplemented

Why is this still incorrectly marked as implemented, 4 years later?

[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.

[joebnb]

4years