Working group dedicated to improving the foundations of async I/O in Rust
Leads: @tmandry and @nikomatsakis
Our meetings take place at 11:30 AM PST every Thursday in our Zulip stream. Feel free to stop by then (or any time!) to introduce yourself.
If you'd like something to work on, check our mentored issues for places to get started. Feel free to claim one of these by adding a comment with the text @rustbot claim.
You can also take a look at our ongoing work to get a sense of what we're up to, and to look for more unclaimed issues you could tackle.
This working group is focused around implementation/design of the “foundations” for Async I/O. This includes the async-await language feature but also the core Future trait and adapters.
The current focus of the group is polishing the async-await feature and working on the async book.
- ✅ Stabilize the
Futuretrait - ✅ Deliver a "minimal viable product" (MVP) introducing
async fninherent functions and async blocks. - ⚒️ Polish the async-await feature, improving diagnostics, spurious errors, and other corner cases.
- ⚒️ Write the async book, which introduces how the core language features in support of Async I/O and teaches you how to use them.
Possible future areas for consideration include:
- Stabilize other core traits in std, such as
AsyncRead - Support async fn in traits
- Support async closures (and possibly an
AsyncFntrait) - Support consuming async streams conveniently (e.g.,
for awaitloops or some similar thing) - Support authoring async streams conveniently via async generators
- Support async drop
However, we've decided to largely defer this sort of work until we've finished off more of the polish work on async-await.
In our weekly triage meetings, we take new issues assigned A-async-await and categorize them. The process is:
- Review the project board, from right to left:
- Look at what got Done, and celebrate! 🎉
- Review In progress issues to check we are making progress and there is a clear path to finishing (otherwise, move to the appropriate column)
- Review Blocked issues to see if there is anything we can do to unblock
- Review Claimed issues to see if they are in progress, and if the assigned person still intends to work on it
- Review To do issues and assign to anyone who wants to work on something
- Review uncategorized issues
- Mark
P-low,P-medium, orP-high - Add
P-highand assignedE-needs-mentorissues to the project board - Mark
AsyncAwait-triaged
- Mark
- If there's still a shortage of To do issues, review the list of
P-mediumorP-lowissues for candidates
If an issue is a good candidate for mentoring, mark E-needs-mentor and try to find a mentor.
Mentors assigned to issues should write up mentoring instructions. Often, this is just a couple lines pointing to the relevant code. Mentorship doesn't require intimate knowledge of the compiler, just some familiarity and a willingness to look around for the right code.
After writing instructions, mentors should un-assign themselves, add E-mentor, and remove E-needs-mentor. On the project board, if a mentor is assigned to an issue, it should go to the Claimed column until mentoring instructions are provided. After that, it should go to To do until someone has volunteered to work on it.
Licensed under either of
- Apache License, Version 2.0 (LICENSE-APACHE or http://www.apache.org/licenses/LICENSE-2.0)
- MIT license (LICENSE-MIT or http://opensource.org/licenses/MIT)
at your option.
Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in this crate by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.