---
title: WG-async roadmap planning 2024-01-25
tags: ["WG-async", "open-discussion", "minutes"]
date: 2024-01-25
discussion: https://rust-lang.zulipchat.com/#narrow/stream/187312-wg-async/topic/Design.20meeting.202024-01-25
url: https://hackmd.io/ZDzG2sySTmm-DrAvI2j1Xw
---

# Roadmap planning for 2024 (second meeting)

Attendance: TC, eholk, yosh, CE, tmandry, Daria Sukhonina

Minutes: TC

This meeting's issue:

https://github.com/rust-lang/wg-async/issues/331

## Project board

https://github.com/orgs/rust-lang/projects/28

## Roadmap planning meeting 20240118

https://hackmd.io/HKBIGY5nSPuhyrcCe0TOHA

## Goals

TC: We were close last week. What were we close on?

tmandry: I started writing it down. There are the things we want to ship, then there are the things that we want to work on.

In terms of what we want to ship:

- I'd like to ship RTN or some equivalent feature.
- I'd like to ship a workaround for AFIDT.
- Async closures.
- And design principles (which might also be something to work on).

Things we want to work on:

- Async Drop
- AsyncIterator / generators
- Maybe async

eholk: That sounds generally good. I think async closures would be powerful; I've been seeing that in the last week or two during experiments.

eholk: RTN would be good also. I hope we can get that also. The lang design meeting yesterday was interesting. There are internal users I know of that have hit the problems solved by this.

eholk: For AsyncIterator, it feels like this is close enough we should be able to ship it.

eholk: We should also work on async Drop. And design principles are good also. We should also think about documentation or things like tools to help control future sizes. I'm not sure we're the best group to do it. But if not, we should maybe take down the async book. In its current state, it's not a great resource.

tmandry: +1 on taking it down or making it a good resource, or at least putting a banner on it pointing to better resources.

TC: +1 on putting a banner on it.

yosh: +1 on putting a banner on it.

yosh: Overall, the list looks right to me. The way I'm looking at this, it's not just for ourselves, but how we'll communicate it publicly. The first set of things are the things we're more confident about. It's about setting expectations. The expectations for the first set are reasonable. The three latter items have more questions.

TC: ...quesion on async generator closures to CE.

CE: On the lang design meeting for RTN, I have some concern about what was proposed for the MVP.

CE: On async generator iterator closures, those are blocked on either the new solver or on introducing three new traits for `LendingFn*`. I wouldn't want to do the async gen closures without working out the trait hierarchy for `LendingFn*`.

TC: It would be worth experimenting.

CE: We landed `AsyncFn` instead of using `LendingFn` at this point.

eholk: What's the timeline on the new solver?

CE: It's years.

TC: So with the new solver, how does that affect the `LendingFn` traits we'd need?

CE: We'd need two traits rather than three.

tmandry: What's the plan on `AsyncFn`?

CE: We have two choices. We can either stabilize `AsyncFn`, or we can add sugar for `async Fn() -> ..`. We can always go back and do the former later. But doing it via sugar leaves more doors open.

yosh: This is also why I'm worried about the interaction with async Drop.

tmandry: The sugared version makes sense to me.

eholk: I like the sugared approach a lot.

TC: +1.

## AsyncIterator

tmandry: There has been much discussion on AsyncIterator. It could seem a bit unsatifying, given all that discussion, to say that we're not going to stabilize something here. It might be better to say that we want to settle the design questions this year and ship it early next year.

TC: It'd be good to pin down the degree to which we actually do or do not have clarity. There seems disagreement even on that point. In recent discussions, I've been trying to build clarity on that.

tmandry: +1. There's the `poll_next` question, and there is the question `poll_pending` question.

TC: +1 on `poll_pending` being a major design point.

yosh: The interaction between async Drop and the AsyncIterator trait specifically, but this applies generally to all async traits.

yosh: Specifically, I'm concerned about stabilizing `AsyncX` trait interfaces. I'm less concerned about `AsyncFn` if we only stabilize it through sugar rather than stabilizing the trait.

eholk: In talking with Yosh, I understand that he's open to later migration in the ecosystem, but he doesn't want to see migration costs imposed when it's stabilized in the standard library.

tmandry: I'm trying to understand, what's the potential interaction between async Drop and the async traits.

yosh: Let's defer that to the meeting next week.

TC: OK, so high level point, we need to nail down to what degree async Drop does or does not affect or block our other plans for stabilizing async things.

## Maybe Async

TC: What do we think about this item?

yosh: I feel like we have clarity among a small group. But we need to sharpen this down and have everyone understand it. There is some dependence on the new trait solver here.

TC: My feeling is that this item has more implication on the stabilization of `AsyncX` things than async Drop, though perhaps the two are a bit tied together.

yosh: +1, that's probably right.

## Concrete deliverables

tmandry: We should maybe think about what the deliverables are for the items on our list.

TC: Perhaps we should describe the items in terms of the problems we're trying to solve.

tmandry: +1 on that.

eholk: If we know the specific solution, we should probably say that. But if it's not clear or there's ambiguity, it becomes harder to trust the roadmap.

TC: +1, that's a good point.

tmandry; Framing in terms of problems we want to solve rather than in terms of solution is something I don't have a strong feeling on. But we should say how far we're going to solve the problem at least.

yosh: Perhaps we should communicate this in terms of finishing what we started.

tmandry: I propose we start an outline of the blog post.

## async Drop

Daria: working on a design around linear types that allows scoped threads. Idea is to add a `Leak` trait so we can have scoped task handles that await in async Drop.

Daria: see https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/The.20destruction.20guarantee.20and.20linear.20types.20formulation/near/417214626. Blog post would be good to read before next week's async Drop meeting.

## Blog post draft

TC: Here's a sketch of ordering:

We start by talking about the problems we've been focused on, and discuss the big things we've done to address them recently, most notably RPTIIT/AFIT. Then we talk about the residue left from that and how we've addressed that with `trait-variant` which will then lead into the further work we're doing to address AFIDT using the trait transformer pattern in `trait-variant`.

The discussion of trait transformers leads into discussion of the problem that RTN solves and the realm of solutions there.

From there, we talk about the further problems that async closures address and the work going forward there.

Then we talk about the problems that underlie the things that we plan to work on this year, including async Drop, async iterators (and async iterator closures), and maybe async.

Then we close with a discussion about design principles.

What do people think about that plot arch?

tmandry: It's important to keep the blog post relatively short, so talking about the problems that underlie some of this work could make the post long.

eholk: We could link to outside posts on these problems to keep things concise.

TC: Agreed, we'd summarize the problem then link to more full resources.

yosh: We should think about what is the purpose of this post? Who are we communicating to?

TC: To ourselves, to the rest of the project, and to everyone else.

tmandry: I agree it's to all three of those.

## Async deliverables

tmandry: Let's nail down the async deliverables.

*Consensus sketch*:

- "A stable solution to the `Send` bound problem for the purpose of solving to the middleware pattern and for adding bounds to RPITIT return types generally."
- PR to `trait-variant`, or some solution to AFIDT in the ecosystem.
- Yosh: Ecosystem solution
- Land async closures in the language in nightly.
- CE: We'll have these soon.
- Lay the groundwork for stabilizing async closures.
- CE: We'll get as close as we can, but who knows? AFIT took us 13 months to stabilize. So we could say we get pretty close. If we can stabilize them sooner, that'd be great.
- Land `async gen` in nightly.
- CE: These are less useful for now until combinators support them.
- Land in nightly `for await` syntax.
- Draft RFC for some solution to the async cleanup problem.
- This could be async Drop, async cancellation, linear types, etc.
- Prototype a solution to the async cleanup problem on nightly (for the purpose of experimentation).
- Draft RFC for `AsyncIterator` trait.
- Yosh: I helped write the original RFC for this, and it's too narrow in scope. The scope really should be at the scope of "async iteration" to cover all aspects of it.
- Draft RFCs for maybe async.
- maybe-async trait definitions.
- maybe-async functions and bounds.
- maybe-async types.
- Draft RFC for async design principles.

(The meeting ended here.)