# Open discussion: May 2023

This is the doc for open discussion within wg-async about various design questions and other topics. Please feel free to propose a topic below.

On the day of the meeting, we'll do a quick poll to sort the topics by interest and then go through them one by one. If you have a brief (under 5 min) introduction prepared for the group, we'll take that into account as we prioritize the topics.

###### tags: `open-discussion`

Leave discussion topics below.

---

## AFIT blog post feedback

tmandry: Placeholder for discussing any interesting feedback we got.

Discussion threads:
- https://old.reddit.com/r/rust/comments/136o73k/stabilizing_async_fn_in_traits_in_2023_inside/
- https://news.ycombinator.com/item?id=35811578

Summary:

* Generally positive
* Some people didn't like all the times you have to write `+ Send`, `+ 'static` etc.
* Nothing revelatory

---

## Lang team discussion updates

tmandry: Summary of lang team discussion yesterday and the upcoming one for next week.

Yesterday: [Return Position Impl Trait in Trait Stabilization](https://hackmd.io/ZEnb67s3RkysfNK2-tBMIw?view)

* Lang team seems on board with stabilizing RPITIT.
* At a high level, most disagreement (from outside the lang team) comes from a belief that this complicates the language rather than simplifies it.
* Question about whether `#[refine]` is worth it ([RFC 3245](https://rust-lang.github.io/rfcs/3245-refined-impls.html)). MVP will not allow you to write impls that require `#[refine]`, i.e., you cannot add extra information like a concrete type or additional bounds to your impl.
* We will allow auto traits to leak without `#[refine]`, so you can write

  trait Foo {
      fn foo(&self) -> impl Future<Output = ()> + Send + '_;
      //                                        ^^^^^^
  }

and it will be compatible with using `async fn` in an impl, once that's stable.

Next week: Associated return types / Return type notation

* RFC draft is still being worked on: [Minimal associated return type notation](/KJaC_dhZTmyR_Ja9ghdZvg)

eholk: Don't love the idea of using an attribute for semantically meaningful things (`#[refine]`)

tmandry: I conceptualize it more as a lint. Semantics are the thing you put in the signature.

eholk: That makes sense

tmandry: Kind of like a shorter `#[allow(...)]`. Maybe we'd stabilize as `#[allow(refine)]`?

eholk: That also looks weird, maybe an argument for just `#[refine]`. Code smell when you `#[allow(..)]` a lot

tmandry: Mod-level `#![allow(..)]` can work

---

## Difference between `async fn` desugaring and RPITIT

tmandry: Let's say you have

trait Foo {
    async fn foo(&self, x: &i32);
}

What does this desugar to? You might think it's something like

trait Foo {
    fn foo<'a, 'b>(&'a self, x: &'b i32)
    -> impl Future<Output = ()> + 'a + 'b;
}

but this promises that the return type outlives `'a` and `'b`, but in reality async fn doesn't promise that. It allows the return type to *name* both `'a` and `'b`, and therefore the return type must be valid while *both* `'a` and `'b` are valid, but that's not the same as saying it outlives both `'a` and `'b`.

it's really more like

trait Captures<T> {}
impl<T, U> Captures<T> for U {}

trait Foo {
    fn foo<'a, 'b>(&'a self, x: &'b i32)
    -> impl Future<Output = ()> + Captures<(&'a (), &'b ())>;
}

The only function of the `Captures` trait is to let you *mention* `'a` and `'b` in the RPITIT, which by the RPITIT rules then allows you to capture those lifetimes in the actual return type.

We can imagine new syntax for this:

trait Foo {
    fn foo<'a, 'b>(&'a self, x: &'b i32)
    -> impl<'a, 'b> Future<Output = ()>;
}

So, what are we doing in the RFC?

1. For stabilizing RPITIT, we only need to consider the case where you use RPITIT in the trait and want to write async fn in the impl later.
* If you have one lifetime, this will "just work" due to existing rules about projections and outlives.
* If you have multiple lifetimes, you can use the `Captures` trick with `async fn`, but it's ugly.
* If you have multiple lifetimes and write `+ 'a + 'b`, I'm not sure with `async fn` in the future. We might find a way to make it work, but you might just need to wait for AFIT to stabilize.

eholk: Can I migrate a trait from `-> impl Future + '_` to `async fn` in the future? In other words, are `-> impl Future + '_` and `async fn` exactly sugar for each other?

tmandry: Yes, when there's one lifetime, but not for multiple lifetimes.

eholk: What does `fn foo(&self, _: &i32) -> impl Future<Output = ()> + '_` correspond to then?

eholk: The capture rules are starting to make me a little concerned. Because AFIT is really desirable, I expect we'll start seeing a lot of `-> impl Future` traits show up in the ecosystem once RPITIT is stabilized. Once AFIT becomes available, crates may want to rewrite their `-> impl Future` traits as `async fn`, but to do that we need to make sure they can write `-> impl Future` in a forward-compatible way. It sounds like that's going to be possible but easy to get wrong with the current plan.

eholk: To be clear though, I don't want to block RPITIT, I think it's a good feature that we should add. I want to make sure we can avoid future footguns though.

---

## Topic

name: prompt

---

## Topic

name: prompt

---