From bbcd85235454c2a5806eed82ded57ac6ac013644 Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Wed, 22 May 2024 11:26:00 -0400 Subject: [PATCH] revise again --- src/2024h2/Async--Drop.md | 68 ++++++++++++++++ src/2024h2/Async.md | 10 ++- src/2024h2/arbitrary_self_types.md | 68 ++++++++++++++++ src/2024h2/cross_cutting.md | 1 + src/2024h2/rfl_arc_unsizing.md | 2 +- src/2024h2/slate.md | 120 +++++++++++++++-------------- src/SUMMARY.md | 5 +- 7 files changed, 212 insertions(+), 62 deletions(-) create mode 100644 src/2024h2/Async--Drop.md create mode 100644 src/2024h2/arbitrary_self_types.md create mode 100644 src/2024h2/cross_cutting.md diff --git a/src/2024h2/Async--Drop.md b/src/2024h2/Async--Drop.md new file mode 100644 index 0000000..e79bcfd --- /dev/null +++ b/src/2024h2/Async--Drop.md @@ -0,0 +1,68 @@ +# Stabilize trait for async streams + +| Metadata | | +| --- | --- | +| Owner(s) | eholk | +| Teams | [Libs-API] | +| Status | WIP | + +[eholk]: https://github.com/eholk +[Libs-API]: https://www.rust-lang.org/governance/teams/library#team-libs-api + +## Motivation + + + +### The status quo + +*Elaborate in more detail about the problem you are trying to solve. This section is making the case for why this particular problem is worth prioritizing with project bandwidth. A strong status quo section will (a) identify the target audience and (b) give specifics about the problems they are facing today. Sometimes it may be useful to start sketching out how you think those problems will be addressed by your change, as well, though it's not necessary.* + +### The next few steps + +*Sketch out the specific things you are trying to achieve in 2024. This should be short and high-level -- we don't want to see the design!* + +### The "shiny future" we are working towards + +*If this goal is part of a larger plan that will extend beyond this goal period, sketch out the goal you are working towards. It may be worth adding some text about why these particular goals were chosen as the next logical step to focus on.* + +## Design axioms + +*Add your [design axioms][da] here. Design axioms clarify the constraints and tradeoffs you will use as you do your design work. These are most important for project goals where the route to the solution has significant ambiguity (e.g., designing a language feature or an API), as they communicate to your reader how you plan to approach the problem. If this goal is more aimed at implementation, then design axioms are less important. [Read more about design axioms][da].* + +[da]: ../about/design_axioms.md + +## Ownership and other resources + +**Owner:** *Identify a specific person or small group of people if possible, else the group that will provide the owner* + +*This section describes the resources that you the contributors are putting forward to address this goal. This includes people: you can list specific people or a number of people -- e.g., 2 experienced Rust engineers working 2 days/wk. Including details about experience level and background will help the reader to judge your ability to complete the work.* + +*You can also include other resources as relevant, such as hardware, domain names, or whatever else.* + +### Support needed from the project + +*Identify which teams you need support from -- ideally reference the "menu" of support those teams provide. Some common considerations:* + +* Will you be authoring RFCs? How many do you expect? Which team will be approving them? + * Will you need design meetings along the way? And on what cadence? +* Will you be authoring code? If there is going to be a large number of PRs, or a very complex PR, it may be a good idea to talk to the compiler or other team about getting a dedicated reviewer. +* Will you want to use "Rust project resources"...? + * Creating rust-lang repositories? + * Issuing rust-lang-hosted libraries on crates.io? + * Posting blog posts on the Rust blog? (The Inside Rust blog is always ok.) + +## Outputs and milestones + +### Outputs + +*Final outputs that will be produced* + +### Milestones + +*Milestones you will reach along the way* + +## Frequently asked questions + +### What do I do with this space? + +*This is a good place to elaborate on your reasoning above -- for example, why did you put the design axioms in the order that you did? It's also a good place to put the answers to any questions that come up during discussion. The expectation is that this FAQ section will grow as the goal is discussed and eventually should contain a complete summary of the points raised along the way.* \ No newline at end of file diff --git a/src/2024h2/Async.md b/src/2024h2/Async.md index 9fa6c7f..9f24838 100644 --- a/src/2024h2/Async.md +++ b/src/2024h2/Async.md @@ -38,7 +38,15 @@ Despite the growth of async Rust, it continues to be significantly more difficul ### Our plan for 2024 -Author an evaluation. XXX expand on this +Author an RFC that will lay out a vision for the Async Rust experience: + +* What works well and what challenges exist in the Status Quo of Async Rust +* Long-term goals (e.g., over next 3-5 years) for async Rust + * Free of accidental complexity + * +* Problems we need to solve to achieve those goals along with possible solutions +* + ### Looking further out diff --git a/src/2024h2/arbitrary_self_types.md b/src/2024h2/arbitrary_self_types.md new file mode 100644 index 0000000..7813b7e --- /dev/null +++ b/src/2024h2/arbitrary_self_types.md @@ -0,0 +1,68 @@ +# Arbitrary self types + +| Metadata | | +| --- | --- | +| Owner(s) | [Adrian Taylor][] | +| Teams | [Compiler], [Libs] | +| Status | WIP | + +[Compiler]: https://www.rust-lang.org/governance/teams/compiler +[Libs]: https://www.rust-lang.org/governance/teams/library +[Alice Ryhl]: https://github.com/Darksonn/ + +## Motivation + +The goal for 2024H2 is to stabilize support for Arbitrary Self Types as described in [RFC 3519][]. This will enable a number of use-cases, including C++ interop (as described in [RFC 3519][]) and the [ARC][] type from the Rust for Linux project. + +[RFC 3519]: https://github.com/rust-lang/rfcs/pull/3519 +[ARC]: https://rust-for-linux.com/arc-in-the-linux-kernel + +### The status quo + +The compiler permits self types for specific "smart pointers" (`Box`, `Rc`, etc) but it is not possible for users to define their own. There has been extensive discussion and design work culminating in the approval [RFC 3519][] with a specific proposal. + +### The next few steps + +This year the goal is to implement and stabilize the design from [RFC 3519][]. + +### The "shiny future" we are working towards + +The ultimate goal is that users are able to define their own smart pointer types with equal capabilities to the builtin options in the standard library. Related and possible future work includes: + +* [Supporting unsizing](./rfl_arc_unsizing.md) +* Ability to move out, as one can do with `Box` +* Integration with matching (e.g., [deref patterns][]) + +[deref patterns]: https://github.com/rust-lang/lang-team/blob/master/projects/deref-patterns.md + +## Design axioms + +None authored. + +## Ownership and other resources + +**Owner:** [Adrian Taylor][] + +[Adrian Taylor]: https://github.com/adetaylor + +### Support needed from the project + +* Reviews from the [compiler] and/or [libs] teams + * QUESTION: Should we assign a reviewer? +* Lang team design is considered "done", but occasional design meetings or triage discussion may be required + +## Outputs and milestones + +### Outputs + +Stable version of the Arbitrary Self Types feature. + +### Milestones + +* Nightly implementation +* Stabilization report +* Stabilization PR + +## Frequently asked questions + +None. \ No newline at end of file diff --git a/src/2024h2/cross_cutting.md b/src/2024h2/cross_cutting.md new file mode 100644 index 0000000..aa1f25b --- /dev/null +++ b/src/2024h2/cross_cutting.md @@ -0,0 +1 @@ +# Cross-cutting improvements diff --git a/src/2024h2/rfl_arc_unsizing.md b/src/2024h2/rfl_arc_unsizing.md index 80f2497..622022e 100644 --- a/src/2024h2/rfl_arc_unsizing.md +++ b/src/2024h2/rfl_arc_unsizing.md @@ -14,7 +14,7 @@ The goal for 2024H2 is to allow the [Rust for Linux's customized ARC type][arc] to use unsized types. The Linux kernel makes extensive use of intrusive linked lists due to their ability to separate *allocation* of a list entry from *insertion* of that entry into the list. While it is possible to safely model intrusive linked lists in Rust with `Pin`, it is complex and unergonomic. -[arc]: XXX +[arc]: https://rust-for-linux.com/arc-in-the-linux-kernel ### The status quo diff --git a/src/2024h2/slate.md b/src/2024h2/slate.md index 800c245..3d2d971 100644 --- a/src/2024h2/slate.md +++ b/src/2024h2/slate.md @@ -2,33 +2,32 @@ > *![Status: Experimental](https://img.shields.io/badge/Status-Experimental-yellow) These goals are still in draft form. They do not represent consensus. Expect changes. The goal column should describe the specific things you aim to get done in 2024H2; the theme ties those into a larger theme (it's ok to put N/A). [Would you like to propose a goal?](../how_to/propose_a_goal.md)* -This page describes the draft roadmap for 2024H2 (second half of 2024). Through conversations with Rust teams and customers, we have identified three **flagship goals** that represent Rust's top priorities at the moment. +This page describes the draft roadmap for 2024H2 (second half of 2024). Through conversations with Rust teams and customers, we have identified two **key flagship goals** that will help advance Rust in particular domains: -* **Async fn everywhere**: Extend Rust's async support to cover the remaining gaps between async and sync, creating a foundation that supports a richer, more reliable, and more interoperable async ecosystem. -* **Linux kernel builds on stable Rust**: Stabilize the key features needed to support safe safe kernel development, using the Rust for Linux project as a testbed. -* **Joyful, scalable Rust teams**: Help the Rust open source project continue to grow and be a rewarding experience. +* **Language support for trait-based async APIs**: Extend Rust language support with the features blocking trait-based, combinator APIs like async iterators, most notably [async closures][AC], and produce a new revision of the Async Vision Doc laying out the plan looking forward. +* **Linux kernel builds on stable Rust**: Stabilize features that block the Rust For Linux project from building on stable Rust. -Important as these three flagship goals are, they don't cover everything. We have therefore included a final section: +In addition, we've assembled a list of **cross-cutting Rust improvements** that will improve the experience of using Rust across the board in ways big and small. Some of these improvements are targeting the functioning of the Rust open-source project itself (assembling this list of goals is one). -* **The other 90%**: Standalone goals that don't directly tie to the above initiatives. The name "the other 90%" is meant to recognize that, while creating a great experience requires big, flashy projects, it *also* requires a ton of other work that often goes unrecognized, ranging from moderation to polish to refactoring. The goals in this section are likely to have the largest impact on your daily usage of Rust. +## Language support for trait-based async APIs -## Async fn everywhere - -Async Rust is a crucial growth area, with a full 52% of the respondents in the [2023 Rust survey](https://blog.rust-lang.org/2024/02/19/2023-Rust-Annual-Survey-2023-results.html) indicating that they use Rust to build server-side or backend applications. Despite that success, async is *also* the most frequently reported challenge to learning Rust. +Async Rust is a crucial growth area, with a full 52% of the respondents in the [2023 Rust survey](https://blog.rust-lang.org/2024/02/19/2023-Rust-Annual-Survey-2023-results.html) indicating that they use Rust to build server-side or backend applications. Despite that success, async is *also* the most frequently reported challenge to learning Rust. Our goals for 2024H2 are to stabilize async closures; solve the send bound problem; and stabilize a trait for async iteration (also called streams). These goals will help propel us towards our long-term vision that async Rust should feel the same as sync Rust, with access to the same range of language support (traits, closures, dynamic dispatch, destructors), library support (including a clear "getting started" experience), and documentation (coverage in the Rust book). -| Goal | Status | Owner | Teams | -| ----------------------------------------------- | ----------- | ------------------- | ------------------ | -| [Revise async vision doc][] | ![WIP][wip] | [tmandry][] | [Lang], [Libs-API] | -| [Stablilize async closures][] | ![WIP][wip] | [compiler-errors][] | [Lang], [Libs-API] | -| [Stable soluton for the "Send bound problem"][] | ![WIP][wip] | [nikomatsakis][] | [Lang], [Libs-API] | -| [Stable trait for async iteration][] | ![WIP][wip] | [eholk][] | [Lang], [Libs-API] | +| Goal | Status | Owner | Teams | +| --------------------------------------------------- | ----------- | ------------------- | ------------------ | +| [Revise async vision doc][AVD] | ![WIP][wip] | [tmandry][] | [Lang], [Libs-API] | +| [Stablilize async closures][AC] | ![WIP][wip] | [compiler-errors][] | [Lang], [Libs-API] | +| [Stable solution for the "Send bound problem"][ASB] | ![WIP][wip] | [nikomatsakis][] | [Lang], [Libs-API] | +| [Stable trait for async iteration][AI] | ![WIP][wip] | [eholk][] | [Lang], [Libs-API] | +| [Complete async drop experiments][AD] | ![WIP][wip] | [petrochenkov][] | [Compiler] | -[Revise async vision doc]: ./Async.md -[Stablilize async closures]: ./Async--AsyncClosures.md -[Stable soluton for the "Send bound problem"]: Async--SendBounds.md -[Stable trait for async iteration]: ./Async--Streams.md +[AVD]: ./Async.md +[AC]: ./Async--AsyncClosures.md +[ASB]: Async--SendBounds.md +[AI]: ./Async--Streams.md +[AD]: ./Async--Drop.md ## Linux Kernel builds on Stable Rust @@ -36,47 +35,50 @@ The experimental support for Rust development in the Linux kernel is a watershed Our goal for 2024H2 is to stabilize the [features required by the Rust for Linux project][rfl]. This works towards our long-term goal of seeing Rust usage throughout kernels and low-level system software. -| Goal | Status | Owner | Teams | -| ------------------------------------------------- | ----------- | -------------------- | ------- | -| [Arbitrary self types][] | ![WIP][wip] | [Adrian Taylor][] | [Lang] | -| [DeriveSmartPointer][] | ![WIP][wip] | [Alice Ryhl][] | [Lang] | -| [Pointers to statics in constants][] | ![WIP][wip] | ![Owner needed][own] | | -| Asm goto (not written) | ![WIP][wip] | ![Owner needed][own] | | -| Offset of (not written) | ![WIP][wip] | ![Owner needed][own] | | -| [RFL on Rust CI][] | ![WIP][wip] | ![Owner needed][own] | [Infra] | -| [Code-generation features and compiler options][] | ![WIP][wip] | ![Owner needed][own] | | -| [Compiling core/alloc][] | ![WIP][wip] | ![Owner needed][own] | | - -## Joyful, scalable Rust teams - -Rust's success is the result of the collective effort of thousands of contributors over time as well as its over XXX [official, long-term maintainers][gov]. But as Rust usage grows, we have seen scaling limits to the current structure: companies and individuals alike report that it can be difficult to follow what the Rust project is doing or to figure out how to contribute and get involved; maintainers find it difficult to grow their teams, resulting in stress and burnout. - -in 2024H2, we aim to improve the situation through a number of efforts, including the process that led to the authoring of this roadmap. Our long-term vision is that members of the Rust teams feel well staffed and well supported. The Rust project governance should operate with transparency, making the current focus clear and making it easy for outside groups to propose new, bold initiatives. - -| Goal | Status | Owner | Teams | -| ----------------------------------- | --------------------------- | -------------------- | ------- | -| [Assemble goal slate][] | [![Accepted][acc]][rfc3614] | nikomatsakis | | -| Track feature stabilization | ![WIP][wip] | | | -| [Finer-grained infra permissions][] | ![WIP][wip] | ![Owner needed][own] | [Infra] | -| Host Rust contributor event | ![WIP][wip] | | | -| Staff team | ![WIP][wip] | | | +| Goal | Status | Owner | Teams | +| ----------------------------------------------- | ----------- | -------------------- | ------------------ | +| [Unsizing in RFL Arc][] | ![WIP][wip] | [Alice Ryhl][] | [Lang] | +| [Arbitrary self types][] | ![WIP][wip] | [Adrian Taylor][] | [Compiler], [Libs] | +| *Owners needed* | | | | +| ↳ RFL on Rust CI | ![WIP][wip] | ![Owner needed][own] | [Infra] | +| ↳ Pointers to statics in constants | ![WIP][wip] | ![Owner needed][own] | [Lang] | +| ↳ Code-generation features and compiler options | ![WIP][wip] | ![Owner needed][own] | [Compiler] | +| ↳ Compiling core/alloc | ![WIP][wip] | ![Owner needed][own] | | + +[Alice Ryhl]: https://github.com/Darksonn/ + +Other issues that may merit goals but would need owners: + +* `asm_goto` [#119364][] : Implemented, needs testing +* `offset_of` [#120140][], [#120141][]: Implemented, needs stabilization report and final decision on syntax + +[Unsizing in RFL Arc]: ./rfl_arc_unsizing.md +[Arbitrary self types]: ./arbitrary_self_types.md +[Adrian Taylor]: https://github.com/adetaylor +[#119364]: https://github.com/rust-lang/rust/issues/119364 +[#120140]: https://github.com/rust-lang/rust/issues/120140 +[#120141]: https://github.com/rust-lang/rust/issues/120141 + +## Cross-cutting Rust improvements + +Many of the most impactful changes to Rust are not tied to a particular domain. This section collects goals of this kind: general-purpose extensions or improvements that impact every Rust user. These can be major changes or they can be addressing a common papercut. In some cases, the goals here are targeted at improving the functioning of the Rust open-source organization, making contributing to and maintaining Rust a more joyful and productive experience. + +| Goal | Status | Owner | Teams | +| ------------------------------------ | --------------------------- | -------------------- | ------------------ | +| [Assemble goal slate][] | [![Accepted][acc]][rfc3614] | nikomatsakis | [LC] | +| [Stabilize Rust 2024 edition][] | ![Accepted][acc] | TC | [LC] | +| [Polonius on nightly][] | ![WIP][wip] | [lqd] | [Lang], [Types] | +| [Impl trait everywhere][] | ![WIP][wip] | [oli-obk] | [Lang], [Types] | +| *Team decision needed* | | | | +| ↳ [Patterns of empty types][] | ![WIP][wip] | [Nadrieril] | [Lang], [Compiler] | +| *Owners and/or team decision needed* | | | | +| ↳ [Relaxing the Orphan Rule][] | ![WIP][wip] | ![Owner needed][own] | [Lang] | +| ↳ [Seamless C support][] | ![WIP][wip] | ![Owner needed][own] | [Lang] | +| ↳ Track feature stabilization | ![WIP][wip] | ![Owner needed][own] | | +| ↳ Finer-grained infra permissions | ![WIP][wip] | ![Owner needed][own] | [Infra] | +| ↳ Host Rust contributor event | ![WIP][wip] | ![Owner needed][own] | | [Assemble goal slate]: ./Project-goal-slate.md - -## "The other 90%" - -Creating a great experience requires a combination of major initiatives (like the previous goals) and continuous polish and incremental improvement. As the saying goes, "we did the first 90% of the work, now we just need to do the other 90%". This section exists to capture important goals taken by teams across Rust which don't directly feed in to one of the above initiatives. Goals in this section are no less important than those in other sections: if anything, they are likely to have a larger impact on your daily usage of Rust. - -| Goal | Status | Owner | Teams | -| ------------------------------- | ---------------- | -------------------- | ------------------ | -| [Stabilize Rust 2024 edition][] | ![Accepted][acc] | TC | [LC] | -| [Relaxing the Orphan Rule][] | ![WIP][wip] | ![Owner needed][own] | [Lang] | -| [Polonius on nightly][] | ![WIP][wip] | [lqd] | [Lang], [Types] | -| [Impl trait everywhere][] | ![WIP][wip] | [oli-obk] | [Lang], [Types] | -| [Seamless C Support][] | ![WIP][wip] | ![Owner needed][own] | [Lang] | -| [Patterns of empty types][] | ![WIP][wip] | [Nadrieril] | [Lang], [Compiler] | - - [rfc3614]: https://github.com/rust-lang/rfcs/pull/3614 [Stabilize Rust 2024 edition]: ./Rust-2024-Edition.md @@ -87,6 +89,7 @@ Creating a great experience requires a combination of major initiatives (like th [Patterns of empty types]: ./Patterns-of-empty-types.md [Polonius on nightly]: ./Polonius.md [Relaxing the Orphan Rule]: ./Relaxing-the-Orphan-Rule.md +[Seamless C support]: ./Seamless-C-Support.md [own]: https://img.shields.io/badge/Owned%20Needed-blue @@ -100,6 +103,7 @@ Creating a great experience requires a combination of major initiatives (like th [nikomatsakis]: https://github.com/nikomatsakis [oli-obk]: https://github.com/oli-obk [tmandry]: https://github.com/tmandry +[petrochenkov]: https://github.com/petrochenkov [Compiler]: https://www.rust-lang.org/governance/teams/compiler [Lang]: https://www.rust-lang.org/governance/teams/lang diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 520a61f..fdd74aa 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -11,11 +11,12 @@ - [Async: Closures](./2024h2/Async--AsyncClosures.md) - [Async: Send bound problem](./2024h2/Async--SendBounds.md) - [Async: Streams](2024h2/Async--Streams.md) + - [Async Drop experiments](2024h2/Async--Drop.md) - [Linux kernel builds on stable Rust](./2024h2/rfl_stable.md) - [Unsizing in RFL Arc](./2024h2/rfl_arc_unsizing.md) - - [Joyful, scalable Rust teams](./2024h2/rust_team_org.md) + - [Arbitrary self types](./2024h2/arbitrary_self_types.md) + - [Cross-cutting improvements](./2024h2/cross_cutting.md) - [Project goal slate](./2024h2/Project-goal-slate.md) - - [The other 90%](./2024h2/other_90.md) - [Rust 2024 Edition](./2024h2/Rust-2024-Edition.md) - [Relaxing the orphan rule](./2024h2/Relaxing-the-Orphan-Rule.md) - [Polonius](./2024h2/Polonius.md)