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:

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

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

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

Select a repo