2023-06-28: Rust 2024 Survey

Information sources

• Also check the async vision document?
• Check in with the const-eval working group to see where they are on their roadmap, or where they will be?
• Check tracking issue labels?

Next steps

• Start a new doc (to avoid losing any information from this one)
• Consolidate across the multiple sources
• Start curating which items might be feasible to push over the finish line for the 2024 edition

blog post

Was posted 2022-04-04

The three high-level goals (may be useful for categorizing/prioritizing):

• Flatten the (learning) curve: scaling to new users and new use cases
• Help Rust's users help each other: scaling the ecosystem
• Help the Rust project scale: scaling the project

The concrete items (not categorized by feasibility or completeness yet):

Flatten the (learning) curve: scaling to new users and new use cases

These items the roadmap listed as "active initiatives" at the time:

• Polonius
• Implied bounds
• async fns in traits (including both static dispatch and dyn dispatch)
• let-else (landed)
• let-chains
• Type-alias impl Trait (TAIT)
• other efforts to expand impl Trait
• Generic Associated Types (GATs) (landed but with current caveats)
• support async fns in traits, including both static dispatch and dyn dispatch.
• Dyn upcasting coercion initiative: Allow upcasting dyn trait objects from &dyn Subtrait to &dyn Supertrait.

These were listed (or implied) as future work:

• deref patterns
• perfect derive
• Autoref, operators, and clones (with work to avoid accidental multiple-references)
• generators
• async drop
• async closures
• "other features needed to support the async vision document roadmap"
  • see also this three-year roadmap
• "Make dyn Trait more usable: Broaden the set of traits that can be used with dyn and make working with dyn closer to working with generics."
• "Make more patterns "object safe" and thus usable in dyn Trait objects, including passing self by value and handling impl Trait in argument position" (see this post).

Help Rust's users help each other: scaling the ecosystem

These items the roadmap listed as "active initiatives" at the time:

• Some solution for the standard library to make use of editions. (edition-based method disambiguation has an RFC; not clear if it's the approach the libs team favors, though.)
• async fn in trait (duplicates an item above)
• constant evaluation
• const generics (we landed only a minimal version of this so far)
• Type-alias impl Trait (duplicates an item above)
• Generic associated types (duplicates an item above)
• Support "global capabilities" like allocators or async runtimes, perhaps via an approach like RFC 2492, and perhaps extending to something like scoped contexts and capabilities.
• Negative impls in coherence
• async portability initiative (building on async fn in trait)

These were listed as future work:

• All ecosystem crates can have "release trains", with the equivalent of "nightly features" that require a stability opt-ins. Top-level crates retain control over whether any of their dependencies may use nightly features.
  • Implies stabilizing stability markers for use outside the standard library
• Allow libraries to implement the Fn traits to define callable objects.
• Variadic tuples and variadic generics
  • There's been new work in this area recently
• Allow libraries to provide custom lints for their users.
• Allow libraries to control or customize Rust diagnostics, especially for trait resolution failures.
• Some solution for what the "portability lint" had tried to address, possibly based on RFC 2492 and/or contexts and capabilities, allowing the standard library to have global capabilities associated with the target
• Find a way to improve coherence rules to make it easier for crates to support interoperability traits, without breaking the benefits of coherence. (Crate A provides a type, crate B provides a trait, right now only A or B can implement the trait for the type. The ecosystem could scale better if someone could write a separate crate AB implementing the trait.)
• Adopt a standard way to write performance benchmarks (perhaps simply adopt criterion officially).
• Better support for dynamic linking, with richer and safer types than the C ABI. For instance, implement an extern "safe" providing a subset of Rust's rich types.
  • Several things in progress in this area: extern "crabi", and a dynamic linking proposal

Help the Rust project scale: scaling the project

These items the roadmap listed as "active initiatives" at the time:

• initiative system and project board
  • Initiative system somewhat nebulous at the moment, has created some uncertainty
  • Have documented concretely the process for "experiments", though
  • Need more work in this area
• Backlog Bonanza: completed, all tracking issues labeled and many followed up on. We may need to do more with the results, though.
• "We're taking the time to stabilize features that people are using, and remove incomplete features as well as features people are not using, with the eventual goal of treating everything open as "in-flight" rather than "unknown". We will also reduce the total number of in-flight features."
  • Some existing features have been stabilized
  • There's work on tagging internal-use-only features that the compiler or standard library use but that there are no plans to stabilize
• "formality team"
  • Done! T-types and T-opsem
• New consensus decision process
  • Process agreed to, but still need tooling before we can start using it; need to check on the status of that tooling

These were listed as future work:

• Find ways to integrate the older tracking issues with active initiatives; reduce the manual updates required to keep the project board in sync.
• Improve the visualization of projects and blockers to something more compelling and easier to follow.
• Forming additional specialized teams where useful
  • Rust scripting/simplification team?
• Other potential improvements to rustbot to make meetings more efficient
• Improve the initiatve process further, in particular going from approved initiative to tracked work

github issues tagged with lang-team-202x-edition

• Change unsafe_op_in_unsafe_fn to be warn-by-default from edition 2024 #112038
  • This would be a pretty disruptive change, but probably good
• Change the lifetime elision rules for dyn Trait #91302
  • Sometimes 'static is not clearly what you want, e.g. on an impl dyn Foo {}, or inside a struct with a lifetime param
  • Generally the inferred 'static can be a source of confusion because it doesn't happen elsewhere in the language
• Make lifetime elision rules for closures consistent with lifetime elision rules for functions #86921
  • Question of whether to infer the lifetimes instead (matklad's comment). This might be harder to implement, but would not be a breaking change (in theory)
• Change meaning of $expr matcher to align with the parser #86730
• Add Debug and Display to the prelude
  • No issue for this, but it annoys me
• Add Hash to the prelude #80361
  • We should consider Debug and Display first, but that would make Hash the only one with a derive but not the corresponding trait in the prelude
• Make pub type foo = bar and pub use bar as foo interchangable in next edition #73191
  • By creating a constructor for foo if bar is a tuple struct
• Change scoping rules for tail expressions to be less surprising #69367
• Deprecate weird nesting of items (mod inside fn, etc) #65516
  • Wanted by rust-analyzer
  • Related to TAIT defining scopes
  • RFC 3373 should fix
• Make indirect_structural_match compatibility lint an error #62411
• Consider deprecation of UB-happy static mut #53639
• Disallow references to static mut #114447
• Clean up items accidentally stabilized through unstable paths #113387

suggestions from comment thread on https://github.com/rust-lang/lang-team/issues/209

RFCs

• Unsafe Extern Blocks RFC #3439
  • Motivation 1: even just declaring certain items can cause UB
    • (namely when doing cross-language compilation; attributes on one function declaration can flow to foreign declaration (pnkfelix Q: or just definition?) and cause miscompilation of it)
  • Motivation 2: Enables declaration of an extern fn that's safe to call.
    • (For functions that are not safe to call, you write unsafe extern { unsafe fn name_of_foreign(...); })
• Unsafe attributes RFC #3325
  • pnkfelix: T-lang has been discussing the syntax here to death, right?
• Add FromLossy and TryFromLossy traits RFC #2484
  • Viewpoint from RFC author: "It is my opinion that we should cover all common conversions performed by the as keyword redundant with std library functionality, and consider deprecating as eventually. Whether this entails traits covering all the above conversions or methods on primitive types for some conversions, or even leaves no alternative to transmute in some cases is beyond the scope of this RFC."
  • pnkfelix: If T-lang concurs with above viewpoint regarding as, we should consider movement in this space.
• Unsafe statics RFC #2937: replace static mut with unsafe static
  • "like statics except they are unsafe to declare and use, and they are not required to implement Sync. Unlike static muts, they do not allow mutable references."
  • an alternative is to "just deprecate static mut without adding any replacement; users using static mut can get a similar effect by creating a newtype around UnsafeCell, which implements Sync"
  • a commenter claims that unsafe fn originally had a design mistake in that it both introduces and also discharges obligations, and that unsafe static would repeat that mistake. (Because it (supposedly) discharges the "safety invariant" which is "static must be Sync".)
    • pnkfelix idly wonders if the answer there is unasfe static = unsafe { ... }; as the form that discharges the Sync invariant for the ... content.
    • but also: I think that both RalfJung and NikoMatsakis have argued that the dual-role of unsafe static is not the same as the double-duty unsafe fn does.
  • see also https://github.com/rust-lang/rust/issues/53639#issuecomment-636051966
• Edition-based Method Disambiguation RFC #3240
  • pnkfelix is not clear on whether T-libs-api itself is happy with the proposal here, and thus it may not be ready for T-lang approval.
• Aligned trait RFC #3319
• Avoid non-local definitions in functions RFC #3373
  • pnkfelix strongly urges T-lang to consider this. Nested non-local definitions are a big Rust footgun. (On the other hand: Would it break how rustdoc does testing of code snippets? If so, is that our problem, or rustdoc's?)
• Extern types v2 RFC #3396
• Explicit move binding mode RFC #3410

Rust Issues

• Make Box<[T]> implement IntoIter rust#59878
  • pnkfelix Q1: can impls be edition-dependent? (Seems questionable.);
  • pnkfelix Q2: also, does it need to be edition-dependent, or is the idea to just make it a new feature that happens to land around the same time as the 2024 edition?
• Open 2018-edition-lints (25 issues as of this writing)
• Open future-incompatibilty (37 issues as of this writing)

Tracking Issues

• Promoting ! to a type rust#35121
  • Concrete example of fallback being hard
    • Normal errors convert from E to Box<E> to Box<dyn Error>👍 using unsizing
    • ! converts from ! to dyn Error💥 to Box<dyn Error>
• #[{doc(cfg(…)),doc(cfg_hide(…)),doc_auto_cfg}] rust#43781
• Reject bounds with type aliases rust#49441
• half_open_range_patterns rust#67264
• unsafe blocks in unsafe fn rust#71668
• infallible promotion rust#80619
• supertrait item shadowing rust#89151
• #[deprecated_safe] attribute rust#94978
• strict provenance rust#95228
• make mem::uninitialized inaccessible rust#98862
• overflowing_literals should have option for "ignore signed overflows" rust#99195
• repr© with overflowing discriminant should warn rust#108969
• refined trait implementations rust#100706

other things that came up after the meeting

• Remove where clauses on type aliases or make them work ("lazy type aliases").
• Make extern blocks unsafe ("unsafe extern").
• Fix "Reordering where clauses can change program behavior" #41756.
• Shorten drop scope of temporaries in conditions #111725.
• Adjust grammar of break to match that of return (dtolnay quiz item 20).
• Fix newline escaping behavior in string literals to match how it was documented for years. See reference#1042.