# 2026 Project Goals planning

## Goals

### [Stabilize Return Type Notation](https://rust-lang.github.io/rust-project-goals/2026/rtn.html)

**Point of contact:** @nikomatsakis
**Champion:**
**Support level:** Large
**Notes:** Stabilization decision, solver work

> Stabilize return type notation (RTN) for trait methods, enabling bounds like `T::method(..): Send` to constrain the return types of async trait methods. Extend RTN to async closures via a new RFC. This unblocks widespread use of async fn in traits and async closures by solving the ["Send bound" problem][sb].
>
> [sb]: https://smallcultfollowing.com/babysteps/blog/2023/02/01/async-trait-send-bounds-part-1-intro/

**Comments:**

(space for team discussion)

Jack: needs a champion, stabilization of current impl blocked on next solver stabilization, new feature work needs someone to impl

Boxy: I don't feel comfortable stabilizing this without stabilizing TAIT first. Opaque types have a history of trying to stabilize stuff that "won't affect the future" and then being wrong and winding up having stabilized stuff that makes the future awkward.

Even with new solver's improved support for opaques there are still some soundness bugs with TAIT. I don't know how long we expect it to be before stabilizing TAIT. Accepting a goal with the intention of stabilizing something where I know we're going to come around to the FCP and I'm going to wind up doing `@rfcbot fcp concern wait-for-tait` doesn't seem correct

I would maybe suggest removing stabilizations from the goal and having it just be about getting everything *ready* for once TAIT is stable?

lcnr: to my knowledge this is pretty much only blocked on "this can be used to get the full behavior of TAIT". Don't think this is useful as a project goal until the new solver is done.

nikomatsakis: I can "rework it to prep RTN + TAIT for stabilization" once trait solver is done

### [Stabilize the next-generation trait solver](https://rust-lang.github.io/rust-project-goals/2026/next-solver.html)

**Point of contact:** @lcnr
**Champion:** @lcnr
**Support level:** Large
**Notes:** Stabilization decision, ongoing review work

> Stabilize `-Znext-solver=globally`, replacing the existing trait solver implementation entirely.

**Comments:**

(space for team discussion)

Jack: +1

Boxy: next-solver y2026 stabilization :pray:

### [Immobile types and guaranteed destructors](https://rust-lang.github.io/rust-project-goals/2026/move-trait.html)

**Point of contact:** @jackh726
**Champion**: @jackh726
**Support level:** Large
**Notes:** Involved in implementation + review

> We propose to introduce new traits that describe what operations are possible on a type. Today Rust assumes all types can be moved (relocated in memory) and forgotten (via `mem::forget`). We will introduce traits like `Move` and `Forget` that make these capabilities explicit, allowing types to opt out. This follows the precedent set by the [Sized hierarchy work](./scalable-vectors.md), which relaxes the assumption that all types have a compile-time-known size. We will implement MVPs in the compiler, write RFCs, and validate viability through real-world testing in the Linux Kernel.

**Comments:**

(space for team discussion)

Jack: Adding myself as champion (which is probably what I should be, not POC). I'd like us to have a design meeting on this at some point.

oli: seems hard to get right and performant, but very interesting

Boxy: very positive about this. i remember yosh talking with me at some point about why a move trait would be useful and I felt fairly convinced it was worth exploring.

lcnr: am involved here and am mentoring this work. Think it's valuable to either actually support this or have clarity that this just isn't possible.

### [Const Generics](https://rust-lang.github.io/rust-project-goals/2026/const-generics.html)

**Point of contact:** @BoxyUwU
**Champion**: @BoxyUwU
**Support level:** Medium
**Notes:** a-mir-formality modeling, design alignment

> Extend const generics in two independent directions, both aiming for stabilization:
>
> * **`adt_const_params`**: Allow structs and enums as const generic arguments, not just integers.
> * **`min_generic_const_args`**: Allow associated constants as const generic arguments (e.g., `Foo<T::ASSOC_CONST>`).
>
> We will also model const generics in `a-mir-formality` and experiment with upstreaming those changes into the Rust specification.
> This work also serves as a forcing function for advancing a-mir-formality and its integration into the Rust specification.

**Comments:**

(space for team discussion)

Jack: Adding Boxy as champion. I think we should aim for stabilization, and we should have a design meeting, so I think this is Large.

Boxy: min_generic_const_args should be ignored here, this is not close to stabilization and I dont think I would expect for that to be realistic for a while. I would definitely like to talk about adt_const_params at a types meeting at some point though, and it will need a types FCP for stabilization so that's Large yeah.

lcnr: :+1:

lqd: IIUC we can clarify the goal to mention only adt_const_params for stabilization?

### [Field Projections](https://rust-lang.github.io/rust-project-goals/2026/field-projections.html)

**Point of contact:** @BennoLossin
**Champion:** @lqd
**Support level:** Medium
**Notes:** Collaborating on a-mir-formality on the borrow checker integration; small reviews of RFC and/or compiler PRs

> We aim to explore and refine the *virtual places* approach for field projections, document its design and interactions in the [beyond-refs wiki](https://rust-lang.github.io/beyond-refs/), implement it as an experiment in the compiler, and prepare RFCs based on the findings.
>
> This is a continuing goal, see [the goal document of the previous period](https://rust-lang.github.io/rust-project-goals/2025h2/field-projections.html) for historical information.

**Comments:**

(space for team discussion)

Jack: Seems good!
oli: yea I have reviewed some of that work. not too interesting type teams wise
lcnr: think it's a Large ask if they want to stabilize it this year, but until then this seems fine to me and worth experimenting

### [Case study for experimental language specification, with integration into project teams and processes](https://rust-lang.github.io/rust-project-goals/2026/experimental-language-specification.html)

**Point of contact:** @jackh726
**Champion**: @jackh726
**Support level:** Medium

> Create an experimental/nightly version of a language specification, based on a branch of the Rust Reference with the addition of stability markers and corresponding tooling. Develop and refine processes around it. (This could theoretically use the Reference directly, but for experimentation purposes it likely makes sense to make it a separate repository, depending on how we can best implement and experiment with this new process without gating on its adoption.)
>
> Do an N=1 case study using the types team as the exemplar, on what it would look like to integrate this with the processes of various teams, with extensive documentation to facilitate scaling this to other teams of domain experts within the project. This case study would include:
> - The handling of proposed changes that fall within the purview of that team, where the types team would review the proposed content.
> - The handling of changes *from* that team, which would be reviewed by other members of the team. This includes ensuring that prospective language changes arising from the work of the team get flagged as needing documentation changes, and the documentation occurs contemporaneously with the language changes.
> - How and when to merge text with unstability markers (whether "unstable text" or "unstable Rust feature"), and what process to follow to review and remove the markers so that text is considered stable.
>
> As a case study, we can use current work on const generics, RTN, or const traits. All of those would heavily overlap with the purview of the types team. (Lang would make design calls on the feel of the language, but the detailed semantics and recommendations typically fall under the types team.)
>
> This goal may potentially align with separate work to improve lang processes, but that work would not be part of this project goal.
>
> This goal will collaborate with the goal to integrate a-mir-formality into language specifications, though neither goal will block on the other.

**Comments:**

(space for team discussion)

Jack: We should discuss a bit about this as a team - I need to outline my plans here, but I'd like to essentially "own" some process for when doing FCPs to ensure we at least are "thinking" about reference changes (and/or a-mir-formality additions). Also, getting early drafts of const-generics text in the experimental reference would be good.

Boxy: Strongly in favour of working towards better processes around the reference. I think there are a lot of details here but picture this is an area that needs a lot of improvement and this is trying to do that. :thumbsup: Happy to use const-generics as a test bed for a new process here- but we should talk 1:1 about what that actually is going to look like (and probably sooner rather than later)

### [Nightly support for function overloading in FFI bindings](https://rust-lang.github.io/rust-project-goals/2026/overloading-for-ffi.html)

**Point of contact:** @ssbr
**Champion**:
**Support level:** Medium

> Design and implement a function overloading system that is suitable for FFI with languages that have overloading. In particular, we aim to make Rust more compatible with C++, so that Rust callers do not place a maintenance burden on C++ library owners due to overloading.

**Comments:**

(space for team discussion)

Jack: Mixed feelings on Medium vs Small. There will be some impl changes to method resolution, and that'll want a types reviewer - but I don't think it needs a *dedicated reviewer*. Given there is no expectation to stabilize, I tend towards Small for us (and, thinking, we should make sure that we note somewhere that this feature will need an impl review prior to trying to be stabilization).
- Jack: I suppose, if someone has specific objections to "anyone on the team can review the impl", then Medium, otherwise Small.

oli: more worried about this on the lang side. but I guess as long as it doesn't allow defining overloaded fns and only declaring them and doing some C++ shenanigans that I don't know how they could possibly work without a C++ compiler being involved during rust compilation....
I don't think Rust should have overloading anywhere beyond the fact that you can have multiple Fn impls. So if they stay in that lane, ok. I will reject PRs adding more things to method resolution.

Boxy: The Fn traits are very special :thinking_face: I would want to have a specific person on types who can own thinking through all the implications of anything that happens there. I definitely wouldn't want to stabilize such a feature off vibes without someone properly sitting down for a while and then being able to tell the rest of types "Yeah looks good to me".

I dont know if that means Small or Medium though :) I suppose anyone can review whatever gets PR'd because its unstable so Small?

lcnr: not sure whether overloading is a big pain point for C++ integration, but I vaguely remember that it is. Seems good as a project goal, expect that it might end up as a medium ask of the types team if they actually implement their approach as they need one of the types team members to review the changes

### [Expanding a-mir-formality to work better as a Rust type system spec](https://rust-lang.github.io/rust-project-goals/2026/a-mir-formality.html)

**Point of contact:** @jackh726
**Champion**: @jackh726
**Support level:** Small

**Notes:** Members may have comments/thoughts on direction and priorities; Review work for a-mir-formality

> The goal here is to begin to move a-mir-formality into a position where it can be used as a formal specification of the Rust type system:
> - Identify type system areas lacking in a-mir-formality
> - Build a "roadmap" to add those lacking areas
> - Continuing to contribute to a-mir-formality and build towards completeness
> - Experiment with integration of a-mir-formality into an experimental reference

**Comments:**

(space for team discussion)

Jack: nothing for the team at large to do, other than perhaps weigh in on a-mir-formality roadmap

Boxy: I think I would like to be more involved in formality going forward- but that's separate from this goal I suppose, and I'm already spending more time on formality than before :)

lcnr: desirable :grin: unsure about the support level. It doesn't require much support, but there's a lot where I would like to be involved

lqd:
- should this mention the formality team idea?
- it seems like the types team should be involved (>small), so I don't yet understand how there is nothing for the team at large to do.

### [Type System Documentation](https://rust-lang.github.io/rust-project-goals/2026/typesystem-docs.html)

**Point of contact:** @BoxyUwU
**Champion:** @boxyuwu
**Support level:** Small
**Notes:** Discussion and moral support

> Improve documentation of type system components to aid in types team onboarding and communication about changes to the type system.

**Comments:**

(space for team discussion)

Jack: +1, go Boxy :)

lcnr: +1

ldq: +∞, invaluable.

### [Sized Hierarchy and Scalable Vectors](https://rust-lang.github.io/rust-project-goals/2026/scalable-vectors.html)

**Point of contact:** @davidtwco
**Support level:** Small
**Notes:** Consultation on stabilization

> Over the next year, we will build on the foundational work from 2025 to stabilize
> the `Sized` trait hierarchy and continue nightly support for scalable vectors:
>
> - Stabilize the refined `Sized` trait hierarchy (without constness), unblocking extern types
> - Propose and implement `const Sized` to support scalable vectors
> - Achieve RFC acceptance for [rfcs#3838] (Scalable Vectors)
> - Land SVE types and intrinsics in stdarch for nightly experimentation
> - Continue addressing stabilization blockers for SVE itself
> - Begin design work for supporting the Scalable Matrix Extension (SME)
>
> The `const Sized` work (Part II of [rfcs#3729]) is deferred to a future goal,
> allowing us to deliver value sooner through the trait hierarchy stabilization.
> This future work interacts with ongoing [const generics][const-generics-goal]
> efforts, as `const Sized` depends on progress in const traits.
>
> [const-generics-goal]: ../2025h2/const-generics.md

**Comments:**

(space for team discussion)

Jack: For stabilization, I think I want this to be Medium, given we've had prior issues with the expanded Sized traits. I want to ensure that *someone* from the team has thought about it enough to convince the rest that the impl is sound/complete.

Boxy: this has nothing to do with const generics, someone needs to PR this goal to say const traits instead. I agree with jack wrt having someone from types heavily involved. I wouldnt be surprised if this winds up being a Large though, previous work on the sized hierarchy has wound up being kind of involved on the whole types team iirc. Definitely not Small though :)

I am looking forward to seeing extern types. Though I think they deserve some thinking about from types before stabilization. They're pretty much a feature that got added forever ago and haven't been thought about since.

lcnr: think the project goal is desirable, do think this is at least Medium, looking at the time I've already spent on this the last year

lqd: just a note that I'll likely take over David for some of this work. Agred on the >=Medium.

### [Crate Slicing for Faster Fresh Builds](https://rust-lang.github.io/rust-project-goals/2026/crate-slicing.html)

**Point of contact:** @yijunyu
**Support level:** Small
**Notes:** Consultation on trait coherence requirements for slicing

> Prototype "crate slicing" — a static analysis technique that computes the transitive closure of items actually used from dependency crates and generates minimal sliced versions, reducing frontend parsing and type-checking overhead during fresh builds.

**Comments:**

(space for team discussion)

Jack: +1, no dedicated person needed
oli: still don't get how any of it makes sense, but if it helps academia figure sth out, and potentially figure out how to explain the results as sth practical... wfm
Boxy: I dont understand this feature :sweat_smile: Answering questions about coherence seems fine though, it's always useful to have people ask stuff to figure out where we're missing docs or whatever.
lcnr: my understanding is that it strips out source code of dependencies if your crate doesn't use them. Certainly fine with the team ask
lqd: vibes aren't great, but no concerns from types perspective

### [Open Enums](https://rust-lang.github.io/rust-project-goals/2026/open-enums.html)

**Point of contact:** @kupiakos
**Support level:** Vibes

> Merge and implement the [unnamed enum variants RFC][enum-rfc] to enable
> ergonomic *open enums* in the language.
>
> [enum-rfc]: https://github.com/rust-lang/rfcs/pull/3894

**Comments:**

(space for team discussion)

Jack: technically changes to type repr of enums, but so minor that vibes is good
lcnr: yeah, seems like it mainly affects layout and syntax, so whatever from a types pov

### [Experiment and RFC for `#[manually_drop]`](https://rust-lang.github.io/rust-project-goals/2026/manually-drop-attr.html) ![Help Wanted][]

**Point of contact:** @thunderseethe
**Support level:** Vibes

> Add a `#[manually_drop]` attribute to
>
> * Allow cross-language bindings to expose struct fields without compatibility hazards, and
> * Make all code that disables default destructor behavior more convenient to use in Rust.

**Comments:**

(space for team discussion)

Jack: May change some type-system code paths, but I imagine they will be "trivial" - vibes is fine
lcnr: jup

### [Assumptions on Binders](https://rust-lang.github.io/rust-project-goals/2026/assumptions_on_binders.html)

**Point of contact:** @BoxyUwU
**Support level:** Medium

> Attempt to implement a version of `-Zhigher-ranked-assumptions` which works for all binders, not just witness types of futures.
>
> Binders (for<'a>) currently don’t track any where clauses involving the bound variables introduced. This leads to many bugs (some soundness bugs) e.g. “that async Send bug” (#149407), or higher ranked subtyping being unsound (#25860).
>
> Figure out a different impl strategy than -Zhigher-ranked-assumptions’s current design then try and implement a prototype.

**Comments:**

(space for team discussion)

lcnr: sgtm :3
Jack: Would love to have a meeting on this :) And am excited to see this.
lqd: note to incorporate https://github.com/rust-lang/rust-project-goals/pull/513#pullrequestreview-3761929578 when opening the PR Jack mentioned to adjust the goals

## Other thoughts

### Goals with missing types support

## [Stabilize Const Traits](https://rust-lang.github.io/rust-project-goals/2026/const-traits.html)

Jack: This needs Large types support. I want a design meeting about this.

Boxy: I think this feature is in a bit of a risky spot where I assume most of the types team doesn't have much of an understanding of how it works (myself included). We should probably try and get that sorted out ASAP so it doesn't wind up being a problem much closer to stabilization

lcnr: yeah, Large

## [reflection and comptime](https://rust-lang.github.io/rust-project-goals/2026/reflection-and-comptime.html)

Jack: Vibes (probably) or Small for us - some type-system impl work is already in, but I could imagine some PRs could still be made
oli: yea all the danger is in semver, and needs a larger discussion anyway

## [Box notation for dyn async trait](https://rust-lang.github.io/rust-project-goals/2026/afidt-box.html)

Jack: Vibes seems appropriate. Not sure that there will be types impl work, but may minorly intersect

lcnr: this changes the dyn compatibility rules. I feel hesitant about accepting this without a good understanding of our long-term plan here. Small

## [Continue Experimentation with Pin Ergonomics](https://rust-lang.github.io/rust-project-goals/2026/pin-ergonomics.html)

Jack: Small or Medium - there have been PRs (and possibly more) effecting e.g. coercion

Boxy: Interacts with coercion/borrowchecker/etc, definitely at least a Small. If this is going to get stabilized I want a t-types FCP and atleast one person on types who understands the whole impl which would make it Medium i think?

lcnr: Small to Medium. Unsure, this goal has a lot of overlap with the Move trait. I personally feel fairly good about `Move` and would prefer that over Pin ergonomics. Given that the `Move` trait isn't guaranteed to succeed, even if I believe it to be likely, it still seems fine for this to exist, but I think most changes are undesirable if `Move` works out

## [Reborrow traits](https://rust-lang.github.io/rust-project-goals/2026/reborrow-traits.html)

Jack: Small - Review work will be on the type-system, but I imagine them to be pretty trivial (and feature-gated, so should add a note to later review)

Boxy: I'd be happy to be involved in this from a types POV if oli can't do so going forward. unsure of the state there :)

## [Implement Supertrait auto impl](https://rust-lang.github.io/rust-project-goals/2026/supertrait-auto-impl.html)

Jack: Small - going to be some logic to ensure coherence rules, etc., aren't violated; may need consulting

Boxy: It wouldn't surprise me if this turns out to be really involved :thinking_face: We previously talked in a types meeting about what strategies for implementing this would be "good" and what would be "scary". I could imagine this goal winding up being in a position where "good" impl strategies are not possible right now and we're left reviewing a PR we don't really want to accept. I think it will probably be fine though, but we could probably do with talking about this and properly communicating such thoughts

lcnr: Think this will be more than small. Certainly the plans wrt to "how to handle potentially overlapping impls" are Medium in that they require somebody to sit down and understand these things.

## [Evolving the standard library API across editions](https://rust-lang.github.io/rust-project-goals/2026/library-api-evolution.html)

Boxy: Will this need changes to HIR ty lowering and method lookup to take editions into account for type dependent name res? If so this is atleast Small

lcnr: in favor, but would like to have a `Small` involvement

## [Rust for Linux in stable: language features](https://rust-lang.github.io/rust-project-goals/2026/Rust-for-Linux-language.html)

Boxy: arbitrary self types/derive coerce pointee very much needs types sign off for stabilization given previous issues here. I don't know what level of support required this is but I've put a tonne of time into this area before- much more than "small". I dont know if that's indicative of future required work though.

I wouldn't be comfortable stabilizing these features without someone from types having spent a bunch of time getting it all in cache and thinking through everything. So Medium to Large?

lcnr: yes, also at least Medium

### Missing: Polonius goal

Niko is planning to open a goal to stabilize the polonius alpha.

### Missing: trait semantics/dictionary passing

Lcnr is planning to open a goal to look into this :>

### Missing: a-mir-formality goal

Niko is planning to open a goal to expand testing, coverage, etc for a-mir-formality.

#

| Goal | Level | Champion | Notes |
| :--- | :---- | :------- | :---- |
| [Stabilize Return Type Notation](https://rust-lang.github.io/rust-project-goals/2026/rtn.html) | Large | @nikomatsakis | Stabilization decision, sol... |
| [Stabilize the next-generation trait solver](https://rust-lang.github.io/rust-project-goals/2026/next-solver.html) | Large | @lcnr | Stabilization decision, ong... |
| [Immobile types and guaranteed destructors](https://rust-lang.github.io/rust-project-goals/2026/move-trait.html) | Large | @lcnr | Involved in implementation ... |
| [Stabilize Const Traits](https://rust-lang.github.io/rust-project-goals/2026/const-traits.html) | Large | @oli-obk | todo |
| [Rust for Linux in stable: language features](https://rust-lang.github.io/rust-project-goals/2026/Rust-for-Linux-language.html) | Large | @jackh726 | todo |
| [Const Generics](https://rust-lang.github.io/rust-project-goals/2026/const-generics.html) | Large | @BoxyUwU | a-mir-formality modeling, d... |
| [Stabilize concrete type specialization](https://rust-lang.github.io/rust-project-goals/2026/specialization.html) | Large | (no champion) | todo |
| [Field Projections](https://rust-lang.github.io/rust-project-goals/2026/field-projections.html) | Medium | @lqd | Collaborating on a-mir-form... |
| [Case study for experimental language specification, with integration into project teams and processes](https://rust-lang.github.io/rust-project-goals/2026/experimental-language-specification.html) | Medium | @jackh726 | |
| [Continue Experimentation with Pin Ergonomics](https://rust-lang.github.io/rust-project-goals/2026/pin-ergonomics.html) | Medium | @oli-obk | todo |
| [Implement Supertrait `auto impl`](https://rust-lang.github.io/rust-project-goals/2026/supertrait-auto-impl.html) | Medium | @BoxyUwU | todo |
| [Sized Hierarchy and Scalable Vectors](https://rust-lang.github.io/rust-project-goals/2026/scalable-vectors.html) | Medium | @lcnr | Consultation on stabilization |
| [Expanding a-mir-formality to work better as a Rust type system spec](https://rust-lang.github.io/rust-project-goals/2026/a-mir-formality.html) | Small | @jackh726 | Members may have comments/t... |
| [Type System Documentation](https://rust-lang.github.io/rust-project-goals/2026/typesystem-docs.html) | Small | @boxyuwu | Discussion and moral support |
| [Crate Slicing for Faster Fresh Builds](https://rust-lang.github.io/rust-project-goals/2026/crate-slicing.html) | Small | | Consultation on trait coher... |
| [Box notation for dyn async trait](https://rust-lang.github.io/rust-project-goals/2026/afidt-box.html) | Small | | todo |
| [Reborrow traits](https://rust-lang.github.io/rust-project-goals/2026/reborrow-traits.html) | Small | | todo |
| [Evolving the standard library API across editions](https://rust-lang.github.io/rust-project-goals/2026/library-api-evolution.html) | Small | | todo |
| [Nightly support for function overloading in FFI bindings](https://rust-lang.github.io/rust-project-goals/2026/overloading-for-ffi.html) | Small | | |
| [Open Enums](https://rust-lang.github.io/rust-project-goals/2026/open-enums.html) | Vibes | | |
| [Experiment and RFC for `#[manually_drop]`](https://rust-lang.github.io/rust-project-goals/2026/manually-drop-attr.html) | Vibes | | |
| [reflection and comptime](https://rust-lang.github.io/rust-project-goals/2026/reflection-and-comptime.html) | Vibes | @oli-obk | |