`.await` does not perform autoref or autoderef

[Jules-Bertholet]

I tried this code:

use core::future::IntoFuture;
use futures::future::{ready, Ready};
struct Foo;

impl IntoFuture for &Foo {
    type Output = u32;
    type IntoFuture = Ready<u32>;

    fn into_future(self) -> Self::IntoFuture {
        ready(2)
    }
}

#[tokio::main]
async fn main() {
    assert_eq!(Foo.await, 2);
}

I expected to see this happen: Compiles and runs successfully. The .await performs auto-ref, and <&Foo as IntoFuture>::into_future() is called.

Instead, this happened:

error[E0277]: `Foo` is not a future
  --> src/main.rs:16:19
   |
16 |     assert_eq!(Foo.await, 2);
   |                   ^^^^^^
   |                   |
   |                   `Foo` is not a future
   |                   help: remove the `.await`
   |
   = help: the trait `futures::Future` is not implemented for `Foo`
   = note: Foo must be a future or must implement `IntoFuture` to be awaited
   = help: the trait `std::future::IntoFuture` is implemented for `&Foo`
   = note: required for `Foo` to implement `std::future::IntoFuture`

Meta

rustc --version --verbose:

1.71.0-nightly (2023-05-12 4a59ba4d54a3ec0d8ea1)

@rustbot label A-async-await

[compiler-errors]

Is there a reason why you want this behavior? Just for consistency? Or do you have real code that relies on it?

[Jules-Bertholet]

This came up for me with the IntoFuture impls for async_once_cell::Lazy. Autoref would make using that type significantly more ergonomic.

[clarfonthey]

Weird question: was this present before the move to IntoFuture? i.e., would this have still failed if &T implemented Future and the value offered was type T?

I'm assuming not, because otherwise this could have potentially broken things that worked before.

[compiler-errors]

@clarfonthey no, afaict it never did autoderef

[eholk]

We discussed this in @rust-lang/wg-async's triage meeting today.

Overall, we'd like to see more motivation for this behavior, especially since on the PR (#111773) it looks like this change could break existing code.

As I understand it, this would let async_once_cell do shared.await instead of shared.as_ref().await. Am I understanding that correctly? Could you give some more examples of what would be possible with this change?

There could be an argument for consistency here, if user's would find it surprising that .await doesn't autoref. As far as I know this is the first case where this has been surprising, but I could easily believe we are missing a lot of cases.

[Jules-Bertholet]

As I understand it, this would let async_once_cell do shared.await instead of shared.as_ref().await.

Basically, yes. Which doesn't sound huge on its own—but let's compare with the sync version of Lazy.

//! Sync version
use once_cell::sync::Lazy; // or `std::sync::LazyLock`

static USER_IDS: Lazy<HashMap<String, u32>> = Lazy::new(|| /* sync initialization code */);

fn johns_id() -> Option<u32> {
    // No `await` and no method call. `Lazy`'s `Deref` impl allows accessing the value directly.
    USER_IDS.get("John Doe").copied()
}

//! Async version
use async_lazy::Lazy; // or `async_once_cell::Lazy`

static USER_IDS: Lazy<HashMap<String, u32>> = Lazy::const_new(|| Box::pin(async {/* async initialization code */}));

fn johns_id_no_autoref() -> Option<u32> {
    // `.await` and extra method call. +14 characters compared to sync version of this code
    USER_IDS.force().await.get("John Doe").copied()
}

fn johns_id_with_autoref() -> Option<u32> {
    // `.await`, but no extra method call. Much closer to sync version, +6 characters
    USER_IDS.await.get("John Doe").copied()
}

There could be an argument for consistency here, if user's would find it surprising that .await doesn't autoref.

Personally, I had always thought that ". means auto(de)ref", and was surprised to learn otherwise. I think this hasn't come up in the past because IntoFuture is not widely implemented, especially on references; without #![feature(impl_trait_in_assoc_type)], it's hard to write the impls. But that feature should stabilize soon.

[tmandry]

We discussed this in a recent wg-async meeting (notes). The consensus was that we thought the change was well-motivated. At the same time, we want to be cautious about introducing problems (namely backwards compatibility).

There should probably be a crater run of this change, and we should also work through any problematic interactions that could be caused by this change. (@rust-lang/types should probably weigh in.)

The main motivation for the change is the analogy to .method(), as well as to wanting async and sync to feel similarly convenient in most cases.

Note that there is another analogy that works against this, the analogy to IntoIterator, where the lang-effect form (for _ in foo {}) does not do autoref/autoderef. However, given that this looks very different from foo.await, and taking a reference with that form is significantly more convenient (for x in &foo or for x in foo.iter() vs (&foo).await), it seemed the analogy was stretched pretty thin. So we elected to put more weight on the above two considerations.

That being said, this change would need lang team signoff. You can consider this comment wg-async's official recommendation to the lang team.