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

# Roadmap planning for 2024

Attendance: TC, CE, eholk, yosh, tmandry

Minutes: TC

---

## Project board

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

## Goals

TC: Let's perhaps update the project board to make concrete our roadmap.

tmandry: I'd like us to have 2-3 things that we agree on as priorities for the year.

## Async closures

tmandry: Async closures should be a priority for us.

CE: Note that, unlike what was discussed in an earlier meeting, these are not almost there.

CE: Still, these are a top priority for me.

## Async drop

yosh: I think it's important that we figure out async Drop this year. We've been punting it for 5 years.

yosh: Huawei is now putting resources into implementing it.

tmandry: Are we creating new interactions that we have to solve for, or is it just the same problems? I don't think, e.g., that async closures will create new problems for async Drop that don't already exist.

CE: I tend to think the same way. We should certainly be doing our due diligence there. But I'm not anticipating problems.

yosh: I just want us to be really very certain. So we should prioritize spending the cycles on it even if we don't make it to stabilization this year.

tmandry: One of the Huawei people working on it posted to IRLO recently. I think I have a clear mental map of the approaches we would take.

- The incomplete one that might rely on post-mono errors.
- The one that would be integrated into the type system with e.g. `?Drop`.

We should probably talk about this as a group.

yosh: We have a call scheduled for this next week.

eholk: The deliverable here is laying out the interactions between this and other features and what the constraints are on async Drop. E.g. what is possible and desirable in terms of its properties.

*Consensus*: Let's mark it as 2024 on the roadmap, and we'll mark it as medium priority, meaning that it is something that we want in some form, and our deliverable is making progress on working out the details.

## Effect generics / maybe async

yosh: This one falls on me. I can commit to writing RFCs for these features, step by step. I won't have the time to implement these myself.

TC: You have three stages as I recall for this.

yosh: As we're designing async features, we should think about the interactions with other language features.

TC: It seems there is a lot of overlap between what's relevant to WG-async and anything else that touches the coroutine transform.

tmandry: I'm open to something like effect generics. I want to be sure we design it around the best design for everything else, rather than designing everything else around effect generics. I'm encouraged that we may have a way to do it, e.g. by composing effect traits while having a path toward generalizing it with e.g. trait aliases.

TC: +1. We have to find ways to make incremental progress.

eholk: I too like the trait aliases thing. I want to be able to ship things in the short term. And then if later we have a way to generalize it, with e.g. trait aliases, that will be a good feature. It reminds me of how people alias `Result`.

CE: We should keep it in mind. If we have things that are really to land, and other theoretical features that may be ready later, the burden of proof of blocking the former is on the latter. We should not paint ourselves into a corner. But we should temper our inclination to block the concrete on the abstract.

*Consensus*: We'll mark this as 2024 on the roadmap and mark it as "medium". It's somewhere between "medium" and "low" based on the standards we had set last year, mostly because we have uncertainty about feasibility.

## Consensus process on draft RFCs

(Discussion about first publishing these as draft RFCs, coming to consensus ourselves, then pushing it to the rest of the project.)

## Design principles

yosh: We should write down our design principles for async Rust.

tmandry: I have thoughts on this. My recent blog post touches on this a bit. Overall, I agree that it would be helpful to talk about a set of design principles and write them down somewhere.

TC/eholk: +1.

## Carryovers

TC: What do we think about the ones carried over? ADFIT, AsyncIterator, and portability for protocol implementations.

tmandry: I don't think that ADFIT needs to be a priority. And portability will come as the result of other things.

tmandry: For AsyncIterator, that one is interesting. I'm not sure we can ship both and and generators by the end of the year, but maybe. We should be experimenting with that in nightly.

tmandry: We also need to prioritize RTN.

CE: We should put dyn on the back burner. And I agree the workarounds are good enough. We should extend `trait-variant` to have a dyn version.

yosh: We regards to generators, we could commit to some part of it, e.g. synchronous generators.

tmandry: In my mind, we'd ship async generators first. That's more squarely needed, and it has been the subject of more discussions.

yosh: I'm worried about the pandoras box that opens up.

TC: Agree with tmandry, but perhaps for a different reason. The difficult part of synchronous generators is that we've already stabilized the `Iterator` trait. For async generators, we have more space.

yosh: Disagree completely. The design of generator blocks has substantial bearing on the design of async iterators.

TC: Actually, I think we agree, with the arrow pointed in the opposite direction. The reasons you think that generators imply a design of async iterators is why I think that it's not easier to do synchronous generators first, because they have many of the same issues as async generators.

## Polish

eholk: Based on feedback from internal teams, there are a lot of polish issues that we should perhaps put on the roadmap.

tmandry: I want to put back lightly, because if we don't have a well defined scope, it's not going to work for a roadmap. I just don't think we have the bandwidth to maintain the async book, e.g.

eholk: Partly this may be about finding the right people. We may need to focus on recruiting those people.

## RTN

tmandry: We should put RTN on the roadmap.

## Finalizing the roadmap

TC: It feels like we're close. Maybe one more meeting. We could use the first week in February slot.

yosh: We could use next week and bump my async Drop a week.

eholk: Agreed, it feels like we're close.

yosh; Could we bump this meeting an hour later next week?

all: +1.