Project-Goals-2026 - The Rust RFC Book

• Feature Name: project_goals_2026
• Start Date: 2026-02-23
• RFC PR: rust-lang/rfcs#3935

Summary

Establish the initial round of Rust Project Goals for 2026 along with a set of current roadmaps, which describe multi-year development arcs.

New Rust Project Goals may be added over the course of the year but only if all required resources (champions, funding, etc) are already known.

Motivation

The 2026 goal slate consists of 66 project goals. In comparison to prior rounds, we have changed to annual goals rather than six-month goal periods. Annuals goals give us more time to discuss and organize.

Why we set goals

Goals serve multiple purposes.

For would-be contributors, goals are Rust’s front door. If you want to improve Rust - whether that’s a new language feature, better tooling, or fixing a long-standing pain point - the goal process is how you turn that idea into reality. When you propose a goal and teams accept it, you get more than approval. You get a champion from the relevant team who will mentor you, help you navigate the project, and ensure your work gets the review attention it needs. Goals are a contract: you commit to doing the work, the project commits to supporting you.

For users, goals serve as a roadmap, giving you an early picture of what work we expect to get done this year.

For Rust maintainers, goals help to surface interactions across teams. They aid in coordination because people know what work others are aiming to do and where they may need to offer support.

Goals are proposed by contributors and accepted by teams

As an open-source project, Rust’s goal process works differently than a company’s. In a company, leadership sets goals and assigns employees to execute them. Rust doesn’t have employees - we have contributors who volunteer their time and energy. So in our process, goals begin with the contributor: the person (or company) that wants to do the work.

Contributors propose goals; Rust teams accept them. When you propose a goal, you’re saying you’re prepared to invest the time to make it happen. When a team accepts, they’re committing to support that work - doing reviews, engaging in RFC discussions, and providing the guidance needed to land it in Rust.

How these goals were selected

Goal proposals were collected during the month of January. Many of the goals are continuing goals that are carried over from the previous year, but others goal are new.

In February, an alpha version of this RFC is reviewed with teams. Teams vet the goals to determine if they are realistic and to make sure that goal have champions from the team. A champion is a Rust team member that will mentor and guide the contributor as they do their work. Champions keep up with progress on the goal, help the champion figure out technical challenges, and also help the contributor to navigate the Rust team(s). Champions also field questions from others in the project who want to understand the goal.

How to follow along with a goal’s progress

Once the Goals RFC is accepted, you can follow along with the progress on a goal in a few different ways:

• Each goal has a tracking issue. Goal contributors and champions are expected to post regular updates. These updates are also posted to Zulip in the #project-goals channel.
• Regular blog posts cover major happenings in goals.

Guide-level explanation

There are a total of 66 planned for this year. That’s a lot! You can see the complete list, but to help you get a handle on it, we’ve selected a few to highlight. These are goals that will be stabilizing this year or which we think people will be particularly excited to learn about.

Important: You have to understand the nature of a Rust goal. Rust is an open-source project, which means that progress only happens when contributors come and make it happen. When the Rust project declares a goal, that means that (a) contributors, who we call the task owners, have said they want to do the work and (b) members of the Rust team members have promised to support them. Sometimes those task owners are volunteers, sometimes they are paid by a company, and sometimes they supported by grants. But no matter which category they are, if they ultimately are not able to do the work (say, because something else comes up that is higher priority for them in their lives), then the goal won’t happen. That’s ok, there’s always next year!

Running Rust scripts will get more convenient with cargo script

People involved: Ed Page

“Cargo script” let’s you create a single file that specifies both a Rust program and the dependencies it needs and then execute that program with one convenient command. For example, you can now take a Rust file like this:

#!/usr/bin/env cargo
---
edition: 2024
[dependencies]
reqwest = { version = "0.12", features = ["blocking"] }
---

fn main() {
    let body = reqwest::blocking::get("https://httpbin.org/ip")
        .unwrap()
        .text()
        .unwrap();
    println!("My IP info: {body}");
}

and run it with cargo my_ip.rs. Or, thanks to the #! line, you can just run ./my_ip.rs.

This feature makes good use of one of the things we found when doing our research for the Vision Doc: that people love Rust not only because it helps them build foundational software, but because it’s a expressive and productive enough that “you can write everything from the top to the bottom of your stack in it” (– Rust expert and consultant focused on embedded and real-time systems). Until now, the fly in the ointment was that packaging up a Rust package required several files and required people to do a separate compilation step. Cargo script solves that problem.

The borrow checker will be more flexible with Polonius alpha

People involved: Amanda Stjerna, Jack Huey, Rémy Rakic, Niko Matsakis, tiif

The “Polonius Alpha” work represents the final completion of the original promise from the 2018 Non-lexical Lifetimes RFC. That RFC originally planned to address three problematic patterns – but ultimately, for efficiency reasons, we were only able to fix two. In the meantime, for the last several years, we have been pursuing work on Polonius, a next generation borrow checker formulation, that aims to close this gap and more.

The Polonius Alpha rules extend the borrow checker to accept the so-called “Problem Case #3” that NLL ultimately failed to solve. This case occurs when you have conditional control flow across functions. For example, in this case the call to map.get_mut(&key), the borrow of map is only “live” in the Some branch, where it is returned (and hence must outlive 'r). But because of imprecision in the borrow checker, the borrow winds up being enforced in the None branch as well, resulting in an error:

fn get_default<'r,K:Hash+Eq+Copy,V:Default>(
    map: &'r mut HashMap<K,V>,
    key: K,
) -> &'r mut V {
    match map.get_mut(&key) { // ──────────────────┐ 'r only needs to
        Some(value) => value,              // ◄────┘ be valid here...
        None => {                          //      │
            map.insert(key, V::default()); //      │
            //  ^~~~~~ ERROR               //      │
            map.get_mut(&key).unwrap()     //      │
        }                                  //      │
    }                                      //      │ ...but today it covers
}                                          // ◄────┘ all this

Under Polonius Alpha, this code compiles.

Polonius Alpha is part of a larger roadmap called the Borrow-Checker Within that we expect to be driving over the next few years. This year, another part of that work is including Polonius Alpha in a-mir-formality, the types team’s (in-progress) specification for how the Rust type system works. As part of another goal, we are planning to integrate a-mir-formality into the Rust reference. This would make Polonius the first version of the borrow checker whose behavior is specified outside of the Rust compiler.

Change const evaluation to support traits, and reflection, allow structs/enums as const parameter types

People involved: Boxy, Deadbeef, Josh Triplett, Niko Matsakis, Oliver Scherer, Scott McMurray, TC

This year we’ll be extending Rust’s support for const evaluation in several ways. To start, you’ll be able to use structs and enums as the values for const generics, not only integers. So where today you can write Array<3>, you’ll be able to write something like this:

pub struct Dimensions {
    pub width: u32,
    pub height: u32,
}

pub fn process<const D: Dimensions>(data: &[f32]) {
    // ...
}

fn main() {
    process::<{ Dimensions { width: 1920, height: 1080 } }>(&data);
}

You’ll also be able to use associated constants as const generic arguments, like Buffer<T::MAX_SIZE>.

Next, we are integrating const into the trait system. When you implement a trait, you’ll be able to provide a const impl which means that the methods in the trait are all const-compatible. const fn can then use bounds like T: const Display to indicate that they need a type with a const-compatible impl or T: [const] Display to indicate that they need a const-compatible impl when called in a const context. Const traits are particularly helpful because they allow you to use builtin language constructs like ? and for loops:

const fn sum_up<I: [const] Iterator<Item = i32>>(iter: I) -> i32 {
    let mut total = 0;
    for val in iter {
        total += val;
    }
    total
}

Finally, we’re beginning early experimental work on compile-time reflection — the ability for const functions to inspect type information. It’s too early to promise specifics, but the long-term vision is things like serialization working without derive macros.

Ergonomic ref-counting and (maybe) async traits

People involved: Takayuki Maeda, Niko Matsakis, Santiago Pastorino

We have a lot of ongoing plans to improve the async Rust experience, but the two most likely to hit stable are more ergonomic ref-counting and extensions to async fn in traits.

The ergonomic ref-counting discussion has gone through many stages, but one solid step everyone agrees on is making it (a) more obvious when you are sharing two handles to the same object vs doing a deep clone, via the Share trait, and (b) more ergonomic to capture clones into closures and async blocks with move($expr) expressions:

// Today: awkward temporary variables
let tx_clone = tx.clone(); // am I deep cloning or what?
tokio::spawn(async move {
    send_data(tx_clone).await;
});

// With Share + move expressions: inline and clear
tokio::spawn(async {
    send_data(move(tx.share())).await;
}); //        ---------------- capture a shared handle

We also plan to cut a “practical path” to support invoking async fns through dyn Trait. The initial version would be limited to boxed futures but the goal is to be forwards-compatible with the ongoing in-place initialization designs for non-boxed allocation (e.g., stack). The RFC for this hasn’t been written yet, and the proposal includes some new syntax, so that could be spicy! Stay tuned.

Try, never, extern types, oh my!

People involved: Amanieu d’Antras, waffle, David Wood, Jana Dönszelmann, lcnr, Niko Matsakis, Tyler Mandry

Three long-awaited features are making their way toward stabilization this year.

The Try trait customizes the behavior of the ? operator, letting you use it with your own types beyond Result and Option. For example, you could define a TracedResult that automatically captures the source location each time an error is bubbled up with ?:

fn read_list(path: PathBuf) -> TracedResult<Vec<i32>> {
    let file = File::open(path)?;  // captures location
    Ok(read_number_list(file)?)    // captures location
}

No more choosing between readable error handling and useful diagnostics.

The never type ! has been unstable for ten years. It represents computations that never produce a value — like functions that always panic or loop forever. The final blockers are being resolved, and stabilization is in sight.

Finally, the Sized trait hierarchy work will stabilize a richer set of sizing traits, which unblocks extern types — another long-requested feature. Today, ?Sized conflates “unsized but has metadata” with “truly sizeless.” The new hierarchy distinguishes these cases. This same work is also laying the foundation for scalable vector support (Arm SVE), where vector sizes depend on the CPU rather than being fixed at compile time.

Going “beyond the &” with better integration for custom pointer types

People involved: Benno Lossin, Alice Ryhl, Mario Carneiro, Ding Xiang Fei, Jack Huey, Niko Matsakis, Oliver Scherer, Tyler Mandry, TC

Three goals this year are working to make it possible for user-defined types to be used in all the ways that you can use Box, Arc, and &.

Arbitrary self types lets you use custom smart pointers as method receivers. With the Receiver trait and derive(CoercePointee), your pointer types work just like Box or Arc — including method dispatch and coercion to dyn Trait:

impl Person {
    fn biometrics(self: &SmartPointer<Self>) -> &Biometrics {
        ...
    }
}

let person: SmartPointer<Person> = get_data();
let bio = person.biometrics(); // just works

Reborrow traits allow custom pointers to be reborrowed, just like mutable references. When working with Pin, for example, you should no longer have to call pinned_ref.as_mut() to fix lifetime issues.

We are also continuing our experimental work to support custom field projections — accessing fields through a smart pointer. Today, &x.field gives you &Field, but there’s no equivalent for NonNull, Pin, or custom pointer types. The field projections design is exploring a “virtual places” approach that would make this work generically. The goal for this year is a compiler experiment on nightly and draft RFCs, with the beyond-refs wiki documenting the design space.

These goals spun out from the ongoing work to support the needs of the Rust for Linux project and are part of the Beyond the & roadmap.

Build it your way with build-std

People involved: David Wood, Eric Huss

A new version of build-std is expected to hit nightly this year. Build-std lets Cargo rebuild the standard library from source, which unlocks things like using std with tier three targets, rebuilding with different codegen flags, and stabilizing ABI-modifying compiler flags. It’s particularly valuable for embedded developers, where optimizing for size matters and targets often don’t ship with a pre-compiled std.

An unstable -Zbuild-std flag has existed for a while, but this new design — progressing through a series of RFCs (one accepted, two more in review) — has a path to stabilization. Build-std is also part of the Rust for Linux roadmap.

Closing soundness bugs and supporting new lang features with a new trait solver

People involved: lcnr, Niko Matsakis

This year, the Rust types team plans to stabilize the next-generation trait solver. This solver is a ground-up rewrite of the core engine that decides whether types satisfy trait bounds, normalizes associated types, and more. The types team has been working on it since late 2022, and it already powers coherence checking as of Rust 1.84. The goal for this year is to stabilize it for use across all of Rust and remove the old implementation.

This goal may not sound like it’s going to impact your life, but finishing the new solver unblocks a lot of stuff. To start, it allows us to make progress on the Project Zero roadmap, which aims to fix every known type system soundness bug. It also unblocks long-desired features like implied bounds, cyclic trait matching, and features needed by the Just add async roadmap.

Roadmaps

Roadmaps offer a “zoomed out” view of the Rust project direction. Each roadmap collects a set of related project goals into a coherent theme. A typical roadmap takes several years to drive to completion, so when you look at the roadmap, you’ll see not only the work we expect to do this year, but a preview of the work we expect in future years (to the extent we know that).

Active roadmaps

Not every goal is part of a roadmap, nor are they all expected to be. This initial set of roadmaps is based on the trends that we saw in the 2026 goals. Over time, we expect to add more roadmaps and refine their structure to help people quickly see where Rust is going.

Reference-level explanation

This section contains the complete list of all 66 goals for 2026. There are a lot of them! You may prefer to look at the roadmaps to get a higher level picture of where Rust is going.

Goals

Goals by size

Large goals

Large goals require the engagement of entire team(s). The teams that need to engage with the goal are highlighted in bold.

Medium goals

Medium goals require support from an individual, the team champion.

Small goals

Small goals are covered by standard team processes and do not require dedicated support from anyone.

Goals by champion

Goals by team

The following table highlights the support level requested from each affected team. Each goal specifies the level of involvement needed:

• Small: The team only needs to do routine activities (e.g., reviewing a few small PRs).
• Medium: Dedicated support from one team member, but the rest of the team doesn’t need to be heavily involved.
• Large: Deeper review and involvement from the entire team (e.g., design meetings, complex RFCs).

“Small” asks require someone on the team to “second” the goal. “Medium” and “Large” asks require a dedicated champion from the team.

book team

*1: Will need approval for book changes. (from here)

bootstrap team

cargo team

*1: Reviews of rust-lang/rfcs#3874 and rust-lang/rfcs#3875 and many implementation patches (from here)

*2: Design and code reviews (from here)

*3: Support needed for registry field design and resolver consistency. (from here)

*4: Code reviews and maybe a design discussion or two (from here)

*5: In case we end up pursuing JITing as a way to improve performance that will eventually need native integration with cargo run. For now we’re just prototyping, and so the occasional vibe check should be sufficient (from here)

*6: PR reviews for Cargo changes; design discussions (from here)

*7: Discussion and moral support (from here)

*8: Alignment on direction, possible integration help and review. (from here)

clippy team

*1: Review our initial batch of lints to ensure they provide an example of adapting the existing lint guidelines to Cargo (from here)

*2: Initial onboarding support for SCRC contributors; guidance on lint design (from here)

*3: Will need approval for clippy support. (from here)

compiler team

*1: Significant refactoring of the resolver, reviews from Vadim Petrochenkov (from here)

*2: My changes should be contained to few places in the compiler. Potentially one frontend macro/intrinsic, and otherwise almost exclusively in the backend. (from here)

*3: Implementation reviews (Oliver Scherer will review Proposal 2) (from here)

*4: Reviews of big changes needed; also looking for implementation help (from here)

*5: Targets are small but async fn is not (from here)

*6: Depending on what ways we end up pursuing, we might need no rustc side changes at all or medium sized changes. (from here)

*7: Design discussions and implementation review. (from here)

*8: Review of implementation PRs; guidance on architecture to avoid previous maintenance issues (from here)

*9: Most will be review work, but pushing optimisations to the max will possibly touch on some controversial points that need discussion (from here)

*10: Champion: Ralf Jung. Design discussions, PR review, and upstream integration. (from here)

*11: Design discussions, PR review (from here)

*12: Standard reviews for stabilization and SVE work (from here)

*13: Reviewing any further compiler changes (from here)

*14: Review our initial batch of lints to ensure they provide an example of adapting the existing lint guidelines to Cargo (from here)

*15: Standard reviews for trait implementation PRs (from here)

*16: Design discussions, PR review (from here)

*17: Reviews of rust-lang/rfcs#3874 and rust-lang/rfcs#3875 and any implementation patches (from here)

*18: Most complexity is in the type system (from here)

*19: Design discussions, PR review (from here)

*20: We expect to only need normal reviews. (from here)

crate-maintainers team

crates-io team

*1: Reviews of rust-lang/rfcs#3874 and rust-lang/rfcs#3875 and any implementation patches (from here)

*2: Primarily focused on potential future logging/bandwidth savings. (from here)

edition team

*1: Review the feasibility of this proposal as well as the specific API changes. (from here)

fls team

*1: Core work of authoring and releasing FLS versions on schedule (from here)

infra team

*1: Critical for setting up the signing pipeline and Azure deployment. (from here)

*2: I will work with Jakub Beránek to add more bootstrap options to build and configure MLIR (an LLVM subproject) (from here)

*3: CI support for MC/DC testing (from here)

lang team

*1: Semantics, syntax, and stabilization decisions (from here)

*2: Design meeting, experiment (from here)

*3: Stabilization decisions, directional alignment (from here)

*4: Aiming for two design meetings; large language feature (from here)

*5: Would need a design meeting and RFC review. (from here)

*6: Design session needed to work through design (from here)

*7: Review and accept a design space RFC (from here)

*8: Stabilization decision for user facing changes (from here)

*9: Reviews, Lang/RfL meetings (from here)

*10: Discussions to understand which parts of gpu programming and std::offload are problematic wrt. stabilization, from a lang perspective. Non-blocking, since we are not rushing stabilization. (from here)

*11: Vibe check and RFC review (from here)

*12: Continued experiment support, design feedback (from here)

*13: This is a stabilization, but we have previously explored the design in detail, and it’s simple and straightforward. It should be able to take place asynchronously. Nonetheless, I can upgrade this to “Large” if people believe it rises to that level. (from here)

*14: Team aligned already on the shape of the feature (from here)

*15: RFC review, design discussions (from here)

*16: Design meeting Experiment (from here)

*17: Champion and (ideally) a lang meeting (from here)

*19: RFC decision for [rfcs#3838], stabilization sign-off (from here)

*20: Stabilization discussions (from here)

*21: Feedback on language semantics questions as needed (from here)

*22: Experimentation with native Wasm features will need approval. May become “medium” if we are somehow really successful. (from here)

*23: Review of the feature and lang implications. (from here)

*24: occasionally being fast-tracked would be nice (from here)

*25: Champion: Tyler Mandry. General support and guidance. (from here)

*26: Will need approval for stabilization. (from here)

*27: Most of the plans / design was already approved, only minor sign-offs required (from here)

lang-docs team

*1: Reviews, Lang/RfL meetings (from here)

*2: Standard PR reviews for Rust Reference (from here)

*3: General discussion of shape of integration of a-mir-formality into reference (from here)

leadership-council team

*1: Org decision to establish team, ongoing coordination (from here)

libs team

*1: Small reviews of library PRs (implementing FP for core & std types) (from here)

*2: Threading support will need review (from here)

*3: Since super let affects the standard library, the library team should be on-board with any new directions it takes. Additionally, library team review may be required for changes to pin!’s implementation. (from here)

*4: Reviews of rust-lang/rfcs#3874 and rust-lang/rfcs#3875 and any implementation patches (from here)

*5: Will need approval for documentation changes. (from here)

libs-api team

*1: Determine what API changes should be made across editions. (from here)

*2: Review RFC; review and approve stdarch SVE APIs (from here)

*3: PR reviews for core/std public documentation; feedback on approach. (from here)

*4: Would like to know if they have use cases for overloading in standard Rust, or if there are certain approaches they would like better. May be involved if experiment involves library surface area (e.g. Fn traits) (from here)

*5: Reviews of RFC and API surface area (from here)

opsem team

*1: Review unsafe patterns, establish safety contracts, guide documentation (from here)

*2: Review pull requests; answer questions on Zulip when there are different opinions about specific rules (from here)

*3: Small reviews of RFC and/or compiler PRs (from here)

*4: Doc changes if necessary (from here)

*5: Problem statement review (from here)

project-exploit-mitigations team

rustdoc team

*1: Figure out how such API changes should be presented in the API docs. (from here)

*2: Design decision and PR review (from here)

*3: Will need approval for rustdoc support. (from here)

*4: Discussion and moral support (from here)

rustfmt team

*1: Will need approval for rustfmt support. (from here)

rustup team

*1: Required for integrating the prototype into the primary toolchain installer. (from here)

spec team

*1: Alignment on release cadence goal (from here)

*2: Will need approval for reference changes. (from here)

*3: General discussion of integration of a-mir-formality with reference (from here)

*4: General discussion on how this may align with other efforts to specify Rust. (from here)

style team

*1: Will need approval for style guide changes. (from here)

testing-devex team

*1: Design discussions and review (from here)

types team

*1: Implementation design and sign-off (from here)

*2: Stabilization decision, ongoing review work (from here)

*3: Review of type-system stabilization/implementation (from here)

*4: a-mir-formality modeling, design alignment, reviews (from here)

*5: Design review, stabilization decision, reviews from Jack Huey and Matthew Jasper (from here)

*6: Involved in implementation + review (from here)

*7: implementation/reviews/deciding on a design (from here)

*8: Collaborating on a-mir-formality on the borrow checker integration; small reviews of RFC and/or compiler PRs (from here)

*9: Stabilization report review, TAIT interactions (from here)

*10: Support for the restricted solver mode in the new solver (from here)

*11: Evaluate potential changes to (experimental) reference in routine team decisions (from here)

*12: Type System implementation and stabilization sign-off (from here)

*13: General discussion on any additional type-system changes (from here)

*14: Review work on the type system is expected to be trivial and feature-gated (from here)

*15: May have changes to dyn-compatibility rules (from here)

*16: Review of any changes to HIR ty lowering or method resolution (from here)

*17: r? types when touching the type system. Expect that anything beyond “simple” types changes may be rejected or de-prioritized. [^types-small] (from here)

*18: No dedicated reviewer needed/given, but tracking issue should note the needed for dedicated types review prior to stabilization (from here)

*19: Discussion and moral support (from here)

*20: Members may have comments/thoughts on direction and priorities; Review work for a-mir-formality (from here)

*21: We expect to only need normal reviews (from here)

wg-mir-opt team

wg-parallel-rustc team

*1: Discussion and Implementation (from here)

Frequently asked questions

How does the goal process work?

Project goals are proposed bottom-up by a point of contact, somebody who is willing to commit resources (time, money, leadership) to seeing the work get done. The point of contact identifies the problem they want to address and sketches the solution of how they want to do so. They also identify the support they will need from the Rust teams (typically things like review bandwidth or feedback on RFCs). Teams then read the goals and provide feedback. If the goal is approved, teams are committing to support the point of contact in their work.

Project goals can vary in scope from an internal refactoring that affects only one team to a larger cross-cutting initiative. No matter its scope, accepting a goal should never be interpreted as a promise that the team will make any future decision (e.g., accepting an RFC that has yet to be written). Rather, it is a promise that the team are aligned on the contents of the goal thus far (including the design axioms and other notes) and will prioritize giving feedback and support as needed.

Of the proposed goals, a small subset are selected by the roadmap owner as roadmap goals. Roadmap goals are chosen for their high impact (many Rust users will be impacted) and their shovel-ready nature (the org is well-aligned around a concrete plan). Roadmap goals are the ones that will feature most prominently in our public messaging and which should be prioritized by Rust teams where needed.

What goal were not accepted?

These goals were not accepted either for want of resources or consensus. In some cases, narrower versions of these goals were proposed instead.