Project Goals 2025h2

• Feature Name: N/A
• Start Date: (fill me in with today's date, YYYY-MM-DD)
• RFC PR: rust-lang/rfcs#3849
• Rust Issue: N/A

§ Summary

Propose a slate of 41 goals for 2025H2.

§ Motivation

The 2025h2 goal slate consists of 41 project goals, of which we have selected a subset as flagship goals. Flagship goals represent the highest priority being done by the various Rust teams.

§ Guide-level explanation

Rust's mission

Our goals are selected to further Rust's mission of making it dramatically more accessible to author and maintain foundational software—the software that underlies everything else. This includes the CLI tools and development infrastructure that developers rely on, the cloud platforms that run applications, the embedded systems in devices around us, and increasingly the kernels and operating systems that power it all.

Foundational software has particularly demanding requirements: reliability is paramount because when foundations fail, everything built on top fails too. Performance overhead must be minimized because it becomes a floor on what the layers above can achieve. Traditionally, meeting these requirements meant choosing between the power-but-danger of C/C++ or the safety-but-constraints of higher-level languages used in very specific ways.

Rust changes this balance by combining zero-cost abstractions with memory safety guarantees, often allowing you to write high-level code with low-level performance. While Rust's primary focus remains foundational software, we also recognize that supporting higher-level applications helps identify ergonomic improvements that benefit all users and enables developers to use Rust throughout their entire stack.

Flagship goals

This period we have 12 flagship goals, broken out into four themes:

• Beyond the &, making it possible to create user-defined smart pointers that are as ergonomic as Rust's built-in references &.
• Unblocking dormant traits, extending the core capabilities of Rust's trait system to unblock long-desired features for language interop, lending iteration, and more.
• Flexible, fast(er) compilation, making it faster to build Rust programs and improving support for specialized build scenarios like embedded usage and sanitizers.
• Higher-level Rust, making higher-level usage patterns in Rust easier.

"Beyond the &"

Goal	Point of contact	Team(s) and Champion(s)
Reborrow traits	[Aapo Alasuutari][]	[compiler] ([Oliver Scherer][]), [lang] ([Tyler Mandry][])
Design a language feature to solve Field Projections	[Benno Lossin][]	[lang] ([Tyler Mandry][])
Continue Experimentation with Pin Ergonomics	[Frank King][]	[compiler] ([Oliver Scherer][]), [lang] ([TC][])

One of Rust's core value propositions is that it's a "library-based language"—libraries can build abstractions that feel built-in to the language even when they're not. Smart pointer types like Rc and Arc are prime examples, implemented purely in the standard library yet feeling like native language features. However, Rust's built-in reference types (&T and &mut T) have special capabilities that user-defined smart pointers cannot replicate. This creates a "second-class citizen" problem where custom pointer types can't provide the same ergonomic experience as built-in references.

The "Beyond the &" initiative aims to share &'s special capabilities, allowing library authors to create smart pointers that are truly indistinguishable from built-in references in terms of syntax and ergonomics. This will enable more ergonomic smart pointers for use in cross-language interop (e.g., references to objects in other languages like C++ or Python) and for low-level projects like Rust for Linux which use smart pointers to express particular data structures.

"Unblocking dormant traits"

Goal	Point of contact	Team(s) and Champion(s)
Evolving trait hierarchies	[Taylor Cramer][]	[compiler], [lang] ([Taylor Cramer][]), [libs-api], [types] ([Oliver Scherer][])
In-place initialization	[Alice Ryhl][]	[lang] ([Taylor Cramer][])
Next-generation trait solver	[lcnr][]	[types] ([lcnr][])
Stabilizable Polonius support on nightly	[Rémy Rakic][]	[types] ([Jack Huey][])

Rust's trait system is one of its most powerful features, but it has a number of longstanding limitations that are preventing us from adopting new patterns. The goals in this category unblock a number of new capabilities:

• Polonius will enable new borrowing patterns, and in particular unblock "lending iterators". Over the last few goal periods we have identified an "alpha" vesion of polonius that addresses the most important cases while being relatively simple and optimizable. Our goal for 2025H2 is to implement this algorithm in a form that is ready for stabilization in 2026.
• The next gen trait solver is a refactored trait solver that unblocks better support for numerous language features (implied bounds, negative impls, the list goes on) in addition to closing a number of existing bugs and unsoundnesses. Over the last few goal periods, the trait solver went from early prototype to being production use in coherence. The goal for 2025H2 is to prepare it for stabilization.
• The work on evolving trait hierarchies will make it possible to refactor some parts of an existing trait out into a new supertrait so they can be used on their own. This unblocks a number of features where the existing trait is insufficiently general, in particular stabilizing support for custom receiver types, a prior project goal that wound up blocking on this refactoring. This will also make it safer to provide stable traits in the standard library, while preserving the ability to evolve them in the future.
• The work to expand Rust's Sized hierarchy will permit us to express types that are neither Sized nor ?Sized, such as extern types (which have no size) or ARM's Scalable Vector Extensions (which have a size that is known at runtime, but not compilation time). This goal builds on RFC #3729 and RFC #3838, authored in previous project goal periods.
• In-place initialization allows creating structs and values that are tied to a particular place in memory. While useful directly for projects doing advanced C interop, it also unblocks expanding dyn Trait to support for async fn and -> impl Trait methods, as compiling such methods requires the ability for the callee to return a future whose size is not known to the caller.

"Flexible, fast(er) compilation"

Goal	Point of contact	Team(s) and Champion(s)
build-std	[David Wood][]	[cargo] ([Eric Huss][]), [compiler] ([David Wood][]), [libs] ([Amanieu d'Antras][])
Promoting Parallel Front End	[Sparrow Li][]	[compiler]
Production-ready cranelift backend	[Folkert de Vries][]	[compiler], [wg-compiler-performance]

The "Flexible, fast(er) compilation" initiative focuses on improving Rust's build system to better serve both specialized use cases and everyday development workflows:

• We are improving compilation performance through (1) parallel compilation in the compiler front-end, which delivers 20-30% faster builds, and (2) making the Cranelift backend production-ready for development use, offering roughly 20% faster code generation compared to LLVM for debug builds.
• We are working to stabilize a core MVP of the -Zbuild-std feature, which allows developers to rebuild the standard library from source with custom compiler flags. This unblocks critical use cases for embedded developers and low-level projects like Rust for Linux, while also enabling improvements like using sanitizers with the standard library or building std with debug information.

"Higher-level Rust"

Goal	Point of contact	Team(s) and Champion(s)
Stabilize cargo-script	[Ed Page][]	[cargo] ([Ed Page][]), [compiler], [lang] ([Josh Triplett][]), [lang-docs] ([Josh Triplett][])
Ergonomic ref-counting: RFC decision and preview	[Niko Matsakis][]	[compiler] ([Santiago Pastorino][]), [lang] ([Niko Matsakis][])

People generally start using Rust for foundational use cases, where the requirements for performance or reliability make it an obvious choice. But once they get used to it, they often find themselves turning to Rust even for higher-level use cases, like scripting, web services, or even GUI applications. Rust is often "surprisingly tolerable" for these high-level use cases -- except for some specific pain points that, while they impact everyone using Rust, hit these use cases particularly hard. We plan two flagship goals this period in this area:

• We aim to stabilize cargo script, a feature that allows single-file Rust programs that embed their dependencies, making it much easier to write small utilities, share code examples, and create reproducible bug reports without the overhead of full Cargo projects.
• We aim to finalize the design of ergonomic ref-counting and to finalize the experimental impl feature so it is ready for beta testing. Ergonomic ref counting makes it less cumbersome to work with ref-counted types like Rc and Arc, particularly in closures.

Project goals

The full slate of project goals are as follows. These goals all have identified points of contact who will drive the work forward as well as a viable work plan. The goals include asks from the listed Rust teams, which are cataloged in the reference-level explanation section below.

Invited goals. Some goals of the goals below are "invited goals", meaning that for that goal to happen we need someone to step up and serve as a point of contact. To find the invited goals, look for the ![Help wanted][] badge in the table below. Invited goals have reserved capacity for teams and a mentor, so if you are someone looking to help Rust progress, they are a great way to get involved.

Goal	Point of contact	Team(s) and Champion(s)
Develop the capabilities to keep the FLS up to date	[Pete LeVasseur][]	[bootstrap] ([Jakub Beránek][]), [lang] ([Niko Matsakis][]), [opsem], [spec] ([Pete LeVasseur][]), [types]
Getting Rust for Linux into stable Rust: compiler features	[Tomas Sedovic][]	[compiler] ([Wesley Wiser][])
Getting Rust for Linux into stable Rust: language features	[Tomas Sedovic][]	[lang] ([Josh Triplett][]), [lang-docs] ([TC][])
Borrow checking in a-mir-formality	[Niko Matsakis][]	[types] ([Niko Matsakis][])
Reborrow traits	[Aapo Alasuutari][]	[compiler] ([Oliver Scherer][]), [lang] ([Tyler Mandry][])
build-std	[David Wood][]	[cargo] ([Eric Huss][]), [compiler] ([David Wood][]), [libs] ([Amanieu d'Antras][])
Prototype Cargo build analysis	[Weihang Lo][]	[cargo] ([Weihang Lo][])
Rework Cargo Build Dir Layout	[Ross Sullivan][]	[cargo] ([Weihang Lo][])
Prototype a new set of Cargo "plumbing" commands	![Help Wanted][]	[cargo]
Stabilize cargo-script	[Ed Page][]	[cargo] ([Ed Page][]), [compiler], [lang] ([Josh Triplett][]), [lang-docs] ([Josh Triplett][])
Continue resolving cargo-semver-checks blockers for merging into cargo	[Predrag Gruevski][]	[cargo] ([Ed Page][]), [rustdoc] ([Alona Enraght-Moony][])
Emit Retags in Codegen	[Ian McCormack][]	[compiler] ([Ralf Jung][]), [opsem] ([Ralf Jung][])
Comprehensive niche checks for Rust	[Bastian Kersting][]	[compiler] ([Ben Kimock][]), [opsem] ([Ben Kimock][])
Const Generics	[Boxy][]	[lang] ([Niko Matsakis][])
Ergonomic ref-counting: RFC decision and preview	[Niko Matsakis][]	[compiler] ([Santiago Pastorino][]), [lang] ([Niko Matsakis][])
Evolving trait hierarchies	[Taylor Cramer][]	[compiler], [lang] ([Taylor Cramer][]), [libs-api], [types] ([Oliver Scherer][])
Design a language feature to solve Field Projections	[Benno Lossin][]	[lang] ([Tyler Mandry][])
Finish the std::offload module	[Manuel Drehwald][]	[compiler] ([Manuel Drehwald][]), [lang] ([TC][])
Run more tests for GCC backend in the Rust's CI	[Guillaume Gomez][]	[compiler] ([Wesley Wiser][]), [infra] ([Marco Ieni][])
In-place initialization	[Alice Ryhl][]	[lang] ([Taylor Cramer][])
C++/Rust Interop Problem Space Mapping	[Jon Bauman][]	[compiler] ([Oliver Scherer][]), [lang] ([Tyler Mandry][]), [libs] ([David Tolnay][]), [opsem]