Tracking issue: a standard library for async Rust

[nrc]

trafficstars

All the parts of various runtimes (and perhaps other crates) that can and should be moved into std.

There are some big issues here, such as whether we could use async overloading for some or all of this? Should APIs be changed to be optimal for completion-based IO?

Then there is a lot of incremental work standardising on parts of the library across runtimes and moving the standardised code into std.

From a high level, the various components are (I expect to further refine and elaborate this list over time, plus add individual issues for items);

• IO traits
• Concurrency primitives (locks, channels, etc.)
• Timers
• Join and select macros
• Pinning utilities

Open issues

[nrc]

Join macro is now in core (unstable): https://github.com/rust-lang/rust/pull/91645

[yoshuawuyts]

Note that similar to https://github.com/nrc/portable-interoperable/issues/5#issuecomment-993558252, stabilization of many of these items will require making a decision on async overloading first. In terms of ordering I feel like we should probably try and clear that hurdle first, as that will determine where in the stdlib many of this functionality should be exposed from.

Async overloading is being tracked on the roadmap, but does not yet have an initiative owner.

[danielhenrymantilla]

A stack-pin!ning macro: https://github.com/rust-lang/rust/pull/93176

[yoshuawuyts]

A stack-pin!ning macro: rust-lang/rust#93176

Maybe we should track "pin utils" as a separate issue. Once we have stack pinning in, the last (?) major remaining issue would be to figure out is how to introduce first-class pin projections into the stdlib.