---
title: wg-async meeting 2023-08-17
tags: deep-dive, wg-async, minutes
date: 2023-08-17
url: https://hackmd.io/G6ULofyXSIS4CK9u-jwYRg
---

# Agenda

* Initial issue: https://github.com/rust-lang/rust/issues/111546
* Autoderef PR https://github.com/rust-lang/rust/pull/111773
* [Analysis of Rust issue #42940](/83sY9XQjSiK79QdnqK0F3Q)

# Attendance

Present: tmandry, TC, yosh, eholk, vincenzo

# Autoderef on `.await` PR

TC: We discussed this in the meeting on Monday. There seem to be tradeoffs here. At a minimum, it probably needs a crater run.

vincenzo: Looks like that the reason is that we could simplify the API:

from:

assert_eq!(shared.as_ref().await.id, 4);

to:

assert_eq!(shared.await.id, 4);

Sure why not? I am not able to see what is the impact of possible api that relay on `as_ref()`?

## Compatibility

tmandry: Can this break existing code? Is this a change we need to consider over an edition?

vincenzo: We should be careful about this, but if it's compatible we should do it.

## Do we feel this just because syntax

tmandry: There's an argument from consistency with method dispatch.

TC: I wonder if we would feel the same way if we had gone with prefix `await` or postfix space syntax.

yosh: I think we would. Striving for async Rust to be like sync Rust, it could make sense.

## "just add a `.await`"

yosh: https://github.com/rust-lang/rust/issues/111546#issuecomment-1557577198

// sync
fn johns_id() -> Option<u32> {
    USER_IDS.get("John Doe").copied()
}

// async, current
fn johns_id_no_autoref() -> Option<u32> {
    USER_IDS.force().await.get("John Doe").copied()
}

// async, proposed
fn johns_id_with_autoref() -> Option<u32> {
    USER_IDS.await.get("John Doe").copied()
}

## Implicit async iterators

Autoref on await would let us do:

let mut iterator = AsyncCountingIterator::new();

let first = iterator.await;
let second = iterator.await;

instead of

let mut iterator = AsyncCountingIterator::new();

let first = iterator.next().await;
let second = iterator.next().await;

## IntoIterator?

tmandry: The other consistency angle I'm thinking of is `into_iterator`. Do we do it there?

let foo = vec![];
// Calls <Vec<()> as IntoIterator>::into_iter():
for x in foo {}
// Calls <&Vec<()> as IntoIterator>::into_iter():
for x in &foo {}

TC: To summarize, when the language uses `into_iter`, as in `for x in y` syntax, it doesn't do `autoderef`. Since `Iterator` and `for` is a similar effect to `Future` and `await`, this is a strong analogy.

tmandry: Agree with that summary.

The original example in the issue was:

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);
}

(&USER_IDS).await

tmandry: People on the lang team have in the past "threatened" to add `.ref` to make that nicer.

yosh: A different way to reason about it could be we should tweak how `into_iterator` works. (Not actually proposing we should though, but it's an option.)

tmandry: It does make me think here, "why couldn't the user just do an `impl IntoFuture` for Foo"?

yosh: [That seems to work?]( https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=f4a947542b4c01973d7a37df960eef27)

eholk: that consumes the `Foo` though. In the example on the issue the thing being awaited is a static so we don't want to (can't?) consume it.

tmandry: Because of postfix `.await`, it's more of a pain to explicitly take a reference. Some lang team members have talked about `.ref` or similar. But we should maybe put more weight on the method dispatch analogy based on this.

TC: What would be the tradeoffs of doing autoderef on `for` loops?

tmandry: It would be confusing.

eholk: With `for` loops there's a convenient place to put the ampersand.

TC: It seems maybe unprincipled to make a decision based only on the syntax that we chose for await rather than its semantic similar to other things in the language.

TC: Do any of the downsides that tmandry mentioned about `for` apply to `.await`?

yosh: Are there any general statements we can make about postfix syntax?

TC: E.g., what if we had postfix `.for(..) { .. }`? How would we feel about that and about the tradeoffs that tmandry raised there?

tmandry: It does feel fine to lean on the syntax for deciding how to look at this.

eholk: `.await` feels like a method call. It's not, but it feels that way.

TC: Interesting aside, during the discussions about choosing the `await` syntax, the fact that postfix dot looked like a field access or method call was one of the downsides people noted.

tmandry: It seems like we need to do a crater run. It's definitely doing to need an FCP from the lang team.

TC: Do we think that t-types will have a feeling on this?

tmandry: Yes, that's a good point, we should collect feedback there. It's be a good stance to say that we want this but that we're cautious about problems.

TC: +1

yosh: Thinking about what you said, TC, about it not being principled.... I do think we want principled designs. If we decide that `.await` should do deref, then we should decide that all postfix syntax should probably do that. We should take that into account. That's definite 100% RFC material and lives on the lang team.

TC: +1

tmandry: +1, there should be some principle.

eholk, vincenzo: +1

TC: Postfix `match` syntax... we couldn't do autoderef for that, that would be weird.

tmandry: Right.

yosh: Is the binding mode thing on `match` related to autoderef?

TC: Not really, it follows a different set of rules.

eholk: Are these under discussion on the language side?

tmandry: We have discussed postfix `match`.

yosh: I know of two examples where postfix `match` is being considered. Here are two examples:

// for-loops
for match in my_iter {
    x => {}
    y => {}
}

// try statements
try { .. } match { .. }

tmandry: That's different than what I think of with respect to postfix `match`. I think of `.match { .. }`.

## Short reprise of `Future::map`

tmandry: We don't really have time to dive into the second issue.

TC: Maybe we could discuss the items from last week for the people who weren't here.

TC: Here's that meeting: https://hackmd.io/LfWcsTSYTPK5TuORJ4l22g

(Discussion about `Future::map`.)

TC: I did have a thought about this after the meeting last week...

TC: Maybe we should just add this method to a separate trait (that could later be implemented by other things like `Option`). So rather than:

pub trait Future {
    fn map<U, F>(self, f: F) -> Map<Self, F>
    where
        F: FnOnce(Self::Output) -> U;
}

We would add:

trait MapOnce<T> {
  type Wrapped<U>;
  fn map<U, F>(self, f: F) -> Self::Wrapped<U>
  where
    F: FnOnce(T) -> U;
}

And we would add an appropriate blanket impl.

(Some discussion followed.)

(The meeting ended here.)