owned this note
owned this note
Published
Linked with GitHub
# Language Team Ideas and Priorities
## General areas and themes
These are a shot at "major themes" where we would expect to pursue projects and project goals. We cover what each theme is, and why it's important. This is based on a variety of factors, such as the [Rust Survey results] and numerous in-person conversations.
[Rust Survey results](https://blog.rust-lang.org/2020/04/17/Rust-survey-2019.html)
* Async I/O
* **What?** Continued improvements with ergonomics and productivity related to Async I/O.
* **Why?** Shows up heavily on the survey, this is an obvious area where a lot of Rust developers are working.
* However, it may be that at this stage, there isn't that much work for **lang** to do -- ideally, this work would be led by the async foundations WG and would be somewhat cross-cutting in nature.
* C Parity, interop, and embedded -- these often overlap in 'low level capabilities'
* **What**? Extending Rust's low-level capabilities to do "things otherwise only possible in C or assembly", as well as enabling smooth, ergonomic FFI between other languages and Rust.
* **Why?** Embedded is a large factor in the survey.
* **Why?** Our ability to act like "native C" is a differentiating capability for Rust. We've seen a lot of traction integrating into big companies on this basis, as a C++ replacement. It's clear that doing this requires the ability to do piecewise adoption.
* Const generics and constant evaluation
* **What?** Supporting
* **Why?** Heavily requested feature and important for key areas.
* Would be good to enumerate use cases.
* Trait and type system extensions
* **What?** Specifically impl Trait, GATs, and specialization
* **Why?** Long-standing areas that affect a lot of domains, including async
* Error handling
* **What?** Combination of [library related improvements](https://blog.yoshuawuyts.com/error-handling-survey/#conclusion) that consolidate "best practices" into standard library, documentation to describe how it works, as well as possible language improvements to leverage those changes (try blocks, `yeet`/`throw` keyword, etc).
* **Why?** Cross-cutting productivity concern, and a persistent problem that makes working with Rust code more difficult than it should be.
* **Why?** Anecdotally, something that comes up for a lot of people (see e.g. [nrc's #rust2020 blog post](https://www.ncameron.org/blog/rust-in-2020-one-more-thing/))
* Borrow checker expressiveness and other lifetime issues
* **What?** Think Polonius, RFC 2229, RFC 66, and other ideas like knowing which fields of `self` are used by particular methods.
* **Why?** Learning curve remains a stubborn problem, and the best way to improve it is to make the compiler smarter.
* Unsafe code capabilities and reference material
* **What?** Document the rules for legal unsafe code and add features that either add required capabilities or make correct code easier and more ergonomic to write.
* **Why?** Growing base of unsafe code, changes here are getting harder, this represents a kind of "reputation risk". We really want to be "better than C" here.
* Targeted ergonomic wins and extensions
* **What?** Small additions or improvements to make Rust easier to use.
* **Why?** These will never rise to the "top of the list", but they often have outsized impact on people's enjoyment of Rust.
* Soundness holes to try and correct
* **What?**
* **Why?** Rust's appeal rests on safety. We have to make steady progress on these points. It's often hard to prioritize them compared to "whiz-bang" features. Also, long-running safety issues can cause fallout when fixed, weakening our stability guarantees.
## Edition changes to prepare
### Pretty safe bet
* Rust 2018 idiom lints
* `gen` keyword for generators
* RFC 2229 -- warnings about drop order changes
### Less clear
* dyn trait soundness hole fixes related to
* https://github.com/rust-lang/rust/issues/57893
* `asm` keyword for inline assembly?
* something to prepare for `let`...`else` (there were some theoretical breaking changes here, right?)
* something to prepare for keyword arguments to function calls
* disallow `foo = bar` in function call position without a disambiguation?
* change `Foo { bar: baz }`?
* my sense is that this change is probably too large
## Short term
"Work to complete by Rust 2021" -- we are trying to calibrate for "things we hope to get done this year".
* Trait and type system extensions, also targeting async
* impl Trait -- nikomatsakis
* Specifically shooting to enable `type Foo = impl Bar` for returning futures etc
* Some implementation complications
* Secondary goal is to outline the remainder of the work and phases to complete it
* GATs and typed HRTBs -- nikomatsakis
* This is largely an implementation challenge at this point, but there is progress happening
* `for<T: Debug> Foo: Trait<T>`
* trait aliases [#41517](https://github.com/rust-lang/rust/issues/41517) -- nikomatsakis
* I'm not sure of the current status here, and would like a "gut check" on how much it matters to close this out
* Josh: implied bounds would make this much lower priority for me, though it's still useful
* Borrow check improvements
* RFC 2229 -- nikomatsakis + matthewjasper are working with some volunteers in t-compiler/wg-
* RFC 66 (stretch)
* C Parity, interop, embedded
* ffi-unwind -- pending RFC but basically done in many respects (nikomatsakis)
* one remaining issue: interaction of `catch_unwind` and foreign exceptions
* safe transmute -- josh
* still in design phase, maybe premature? looks "completable" though by 2021
* inline assembly -- josh
* implementation has landed
* Hopefully we can stabilize in 2021
* `raw_ref!` / `raw_ref_mut!` macros -- basically done
* Unlocks working unaligned accesses
* Unlocks offsetof
* Better linker support, including full linker scripts and simple attributes for common options
* XXX status and person?
* Error handling? (wildcard, see notes below)
* library improvements?
* This isn't really "our job"
* Stabilize `Try` trait
* It seems like our ability to make changes here is limited, should we just close this out?
* Unsafe code guidelines
* Layout, safety, and validity invariants (majority of them)
* unsafe op in unsafe fn
* Targeted ergonomic wins or smaller features
* label-break-value [#48594](https://github.com/rust-lang/rust/issues/48594)
* `let...else` or similar (if let / exit function) -- targeted ergonomic wins
* [RFC 2497](https://github.com/rust-lang/rfcs/pull/2497) for `if condition && let` chains -- targeted ergonomic wins
* type privacy, private in public -- targeted eronomic wins
* pattern matching improvements like slice patterns, `|` patterns, etc -- targeted ergonomic wins [#54883](https://github.com/rust-lang/rust/issues/54883)
* largely implemented but contains a few unresolved questions that would require some crater runs
* non-ascii identifiers [#55467](https://github.com/rust-lang/rust/issues/55467)
* Significant concerns raised, do we want to push on these?
* turbofish? -- targeted eronomic wins
* [crate visibilty](https://github.com/rust-lang/rust/issues/53120) -- targeted ergonomic wins
## Mid-range
"Could start now, don't expect to really stabilize and transition until after Rust 2021." These are good candidates, though, for reserving keywords or syntactic space.
* Const generics and const evaluation
* Unsafe code ergonomics
* Polonius integration
* Implied bounds
* Delegation
* Error handling language changes ?
* SIMD ? (maybe worth boosting this? or is it blocked on const generics?)
## Longer range or blocked
* Borrow checker:
* knowing what fields private methods use
* interior references (blocked on Polonius)
* implied bounds (blocked-ish on chalk)
* Specialization
* C Parity, interop, and embedded -- these often overlap in 'low level capabilities'
* we'll progress, but I don't want to put significant effort until we've resolved the other trait related issues
* https://paper.dropbox.com/doc/FFI-C-Parity-working-group--AzY5D4DrXOiGThxOlu9kIH99Ag-5NmXV30TGiSsr9dIxpqpq
* First-class C integration (look at what Zig does here)
* First-class `bindgen`: `#include` from Rust
* First-class `cbindgen`
* First-class C compiler: `rustc foo.rs bar.c`
* Variadic generics
## Edition 2021
* crate visibility
* trait aliases
* if let / exit function
* type privacy, private-in-public