Yosh's async roadmap

# Yosh's async roadmap I'd like us to have to have an emphasis on shipping things. We're pretty close on some items, and we have some items which we can make progress on. This document starts by describing the relationship between items, and then proposes an ordering + timeline which we can use to ship things. This should not be considered a final proposition; but a starting point for discussion. My hope is that we can agree on a rough ordering, dependencies, and then work towards actually shipping things. ## Vision The vision underpinning this is that async Rust should act as a superset of non-async Rust. At least as capable, but with some extra things which are unique to async Rust. This means we go through things in this order: 1. Bring async Rust lang capabilities up to par with non-async Rust 2. Asyncify the stdlib, starting with traits, then types 3. Add APIs which capitalize on the unique capabilities provided by async Rust 4. Finally figure out the generic interfaces to make all this pluggable by other backends (a la `#[allocator]` or similar). ## Core items The WG's priority should be to ship the missing language items. This includes (in order): - `async fn` in traits - `?async fn` ("maybe-async functions") - `?async Drop` / `async Drop` trait - `?async {Fn,FnMut,FnOnce}` ("async closures") - `for await..in` syntax Then after that are the interface types. These include (unordered): - `?async Iterator` - `?async Read` - `?async Write` And finally there are the concrete types and functions, which include: - `?async TcpStream` - `?async File` - `?async UdpSocket` Then there are the items which are currently _not_ blocked, and we can knock out at any time if we want to get a quick win. It requires design work, but it's otherwise not dependent on anything else: - `impl Future for (T..)` / `impl Future for [T;N]` / `impl Future for Vec<T>` - `async fn main` / `#[test]async fn` - `thread::block_on` - `task::sleep` - `future::Race` - `ParallelFuture` (or some other structured alternative to `task::spawn`) What's not included in this list yet is _compatibility interfaces_. This means things like: "define an interface which can back, say, `?async File`". In order to decide what this interface should look like, we first must decide what `?async File` will look like. Which we won't know the exact scope for until we have the types in std. I believe we should let std inform these interfaces, rather than let std be informed by these interfaces. So that's why I believe this should come last. ## Roadmap ### January 2023 - June 2023 - 1. (concurrent) - design AFIT `send`-bounds - `impl Future for (T..)`, `impl Future for []`, `impl Future for Vec` on nightly - 2. (concurrent) - `?async fn` MVP on nightly - stabilize AFIT + `send`-bounds - 3. (concurrent) - `?async Iterator` on nightly - `?async Read` on nightly - `?async Write` on nightly - 4. `for await..in` on nightly ### July 2023 - Dec 2023 The timelines here become far more murky, but the priority should be to ship AFIT first. And that needs `send`-bounds. Next up is `?async fn`, and then the interface types. 1. Stabilize AFIT `send`-bounds 2. Stabilize AFIT 3. Stabilize `?async fn` MVP ... more?