Rust: 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:

• [x] Implement the RFC
• [ ] Adjust documentation (see instructions on rustc-guide)
• [ ] Stabilization PR (see instructions on rustc-guide)

Unresolved questions:

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

[CGQAQ]

@Nemo157

async fn a() -> Result<(), reqwest::Error> {Ok(())}
async fn b() -> Result<(), std::io::Error> {Ok(())}

fn c() {
    async {
        a().await?;
        b().await?;
        Ok(())
    };
}

error[E0282]: type annotations needed
 --> src/x.rs:6:9
  |
6 |         a().await?;
  |         ^^^^^^^^^^ cannot infer type

error: aborting due to previous error



md5-dc16549e84993d783ce89446c0cbf619

error[E0562]: impl Trait not allowed outside of function and inherent method return types
--> src/x.rs:8:18
|
8 | Ok::<(), impl std::error::Error>(())
| ^^^^^^^^^^^^^^^^^^^^^^

error: aborting due to previous error
```

[Nemo157]

@CGQAQ the former _is_ unconstrained, there's no way rustc can know what the error type should be, changing it to be used in a closure returning an async block passed to a function which constrains it works fine (and the equivalent blocking code also fails). The latter already works after replacing impl Error with a concrete error type (as far as I'm aware impl Trait in that position is not supported and has not been RFCed). (I also switched both to use serde_json::Error instead of reqwest::Error as it provides the necessary conversion into io::Error).

If you want to continue this it would be best to open a new issue and ping me there (or discord) to avoid notifying subscribers of this issue.

[cdbattags]

Any recent news/updates for this feature?

[Centril]

The purpose of this issue to track the development by noting relevant PRs and whatnot as they happen. The feature gate label is also available to route you to relevant places. You can assume that if no recent developments have been noted here, or linked, or provided in the issues with the label, that there are no such developments, so please avoid asking about it here.

[Pzixel]

Sorry if I missed it, but what's the motivation under this feature? IMO It just adds a slightly different syntax for existing thing (async || vs || async), introducing confusion with no foreseeable benefit. Or at least this is what I see here.

Could you elaborate on that, please?

[khionu]

|| async { } is not an async closure, it's a closure that contains an async block.

[Pzixel]

Yes, I see it, but what's the difference from the user perspective?

[Nemo157]

There may be differences in how lifetimes in the arguments are treated once they’re supported. Also elaborating the return type is not possible with the closure to async block (playground)