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

[traviscross]

@rustbot labels -I-types-nominated

This was discussed at a recent T-types meeting. The consensus was that this is a question for T-lang. If T-lang has a specific question for T-types, please renominate.

[estebank]

In the meantime we could change the error to check for the same steps that autoderef would follow and suggest the right combination of operations (suggest (&Foo).await here).

[WaffleLapkin]

While I sympathize with the example of async Lazy, I don't think this is a good solution. Or, rather, that seems like a too radical approach, for a small problem. I would not expect .await to auto ref (the same as with for loop) and I don't think we need to complicate .await with that.

What I would rather see is postfix address of operator, which would let you take the reference without adding parenthesis: lazy.&.await. Compiler then can suggest adding it, as @estebank suggested above.

(I'm a bit biased here cause I want postfix addr-of anyway, but making .await do autoref really does not sound like a good idea to me...)

[tmandry]

Given that there's been a crater run and we haven't looked through the results yet, unnominating until @rust-lang/wg-async has time to do so.

@rustbot label: -I-lang-nominated

[tmandry]

I'd like to use this issue to collect more use cases in the meantime. Right now this seems like a risky change to make, when so far we only know of one instance where it would be useful.

[clarfonthey]

I definitely think that this should be something that happens, even if it has to happen in a future edition. (I'd imagine it's probably too late to nudge into the 2024 edition, given the amount of work required and the short deadline.)

I also believe that . should just always do auto-deref, and that includes for cases like .await. Probably the only future exception might be postfix macros (I wouldn't expect x.macro!() to auto-deref since it's a syntactical thing, and it wouldn't know what to deref to in general) but I don't think there's any existing cases where it doesn't auto-deref.

.& might itself be useful in combination with .* and postfix macros though. Perhaps .* and .& could be paired together in an RFC.