Skip to content
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

Diagnostics request: suggest a closure with an async block when an async closure is encountered #71686

Open
jebrosen opened this issue Apr 29, 2020 · 1 comment
Labels
A-async-await A-closures A-diagnostics AsyncAwait-Triaged C-enhancement F-async_closures T-compiler

Comments

@jebrosen
Copy link
Contributor

@jebrosen jebrosen commented Apr 29, 2020

Consider the following code (playground):

use std::future::Future;

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

fn main() {
    // error[E0658]: async closures are unstable
    let fut1 = wants_closure_returning_future(async || 3);
    
    // Fine, and what should have been used anyway
    let fut2 = wants_closure_returning_future(|| async { 3 });
}

With the following output:

error[E0658]: async closures are unstable
  --> src/main.rs:13:47
   |
13 |     let fut1 = wants_closure_returning_future(async || 3);
   |                                               ^^^^^
   |
   = note: see issue #62290 <https://github.com/rust-lang/rust/issues/62290> for more information

In many cases moving the async keyword fixes the error and is "good enough" despite the differences in semantics, so it would be nice if the compiler could suggest this as well:

  = help: try returning a future instead: `|| async { 3 }`

This is also easy to run into when using futures or stream combinators such as then, especially for someone who is not yet very familiar with async/await.

@Dylan-DPC-zz Dylan-DPC-zz added A-diagnostics F-async_closures labels Apr 29, 2020
@jonas-schievink jonas-schievink added A-async-await C-enhancement T-compiler A-closures labels Apr 29, 2020
@tmandry tmandry added this to On deck in wg-async work via automation May 12, 2020
@tmandry tmandry added the AsyncAwait-Triaged label May 12, 2020
@tmandry tmandry removed this from On deck in wg-async work Jul 28, 2020
@Ugator
Copy link

@Ugator Ugator commented Mar 10, 2021

Why does a compiler hint to not use an unstable feature depend on that unstable feature to be stabilized? It seems to me that the design pattern of "luring people into unstable" is questionable anyways, so when we can suggest an alternative that should have priority over hinting towards unstable.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-async-await A-closures A-diagnostics AsyncAwait-Triaged C-enhancement F-async_closures T-compiler
Projects
None yet
Development

No branches or pull requests

5 participants