---
title: "Design meeting 2026-02-04: 2026 Goals review"
tags: ["T-lang", "design-meeting", "minutes"]
date: 2026-02-04
discussion: https://rust-lang.zulipchat.com/#narrow/channel/410673-t-lang.2Fmeetings/topic/Project.20goals.20meeting.202026-02-04/
url: https://hackmd.io/sifcXBs3TZeF1FUgWRDm3A
---

# Goals review for lang team (2026)

## Attendance

- People: TC, Niko, tmandry, Josh, James Muriuki, Zachary Sample (zachs18), Tomas Sedovic, Jack Huey, David Wood, dianne, Mark (simulacrum), Nadri, Nurzhan, Benno, scottmcm, Chris Sena

## Meeting roles

- Driver: TC
- Minutes: Tomas

## What does small|medium|large means?

Here are some rules of thumb and historic examples, focusing on lang + compiler:

| Task | Lang | Compiler |
| --- | --- | --- |
| Adding a lint | Small | Small |
| Landing a complex compiler change | - | Medium |
| Driving an early stage lang experiment | Medium | Medium |
| Accepting a lang RFC | Large | Medium |
| Stabilizing a lang feature | Large | Medium |
| Vet and stabilize subtle reference changes | Large | - |
| Overhaul compiler's incremental system | - | Large |

## What are we assessing here?

Ask yourself:

* Do we want to do this? Are you concerned about this goal in a general sense? Is it *directionally* reasonable?
* Would you be willing to champion (excluding capacity)? Go ahead and write in if you would, even if it already has a champion.
* Does the scope seem plausible to get done in 2026?
* Does the ask look like it's proportionate to the benefit, and sufficient to make the work successful?

## Summary by support level

| Goal | Level | Champion | Notes |
| :--- | :---- | :------- | :---- |
| [reflection and comptime](https://rust-lang.github.io/rust-project-goals/2026/reflection-and-comptime.html) | Large | @scottmcm | Design meeting, experiment |
| [Const Generics](https://rust-lang.github.io/rust-project-goals/2026/const-generics.html) | Large | @nikomatsakis | Stabilization decisions, di... |
| [Field Projections](https://rust-lang.github.io/rust-project-goals/2026/field-projections.html) | Large | @tmandry | Aiming for two design meeti... |
| [Redesigning `super let`: Flexible Temporary Lifetime Extension](https://rust-lang.github.io/rust-project-goals/2026/redesigning-super-let.html) | Large | | Would need a design meeting... |
| [Stabilize Return Type Notation](https://rust-lang.github.io/rust-project-goals/2026/rtn.html) | Large | @nikomatsakis | Stabilization decision |
| [Immobile types and guaranteed destructors](https://rust-lang.github.io/rust-project-goals/2026/move-trait.html) | Large | | Design session needed to wo... |
| [In-place initialization](https://rust-lang.github.io/rust-project-goals/2026/in-place-init.html) | Medium | | |
| [Stabilize the next-generation trait solver](https://rust-lang.github.io/rust-project-goals/2026/next-solver.html) | Medium | @nikomatsakis | Stabilization decision for ... |
| [Project goal - High-Level ML optimizations](https://rust-lang.github.io/rust-project-goals/2026/high-level-ml.html) | Medium | @traviscross | Discussions to understand w... |
| [Experiment and RFC for `#[manually_drop]`](https://rust-lang.github.io/rust-project-goals/2026/manually-drop-attr.html) | Medium | | Vibe check and RFC review |
| [Reborrow traits](https://rust-lang.github.io/rust-project-goals/2026/reborrow-traits.html) | Medium | @tmandry | Continued experiment suppor... |
| [Box notation for dyn async trait](https://rust-lang.github.io/rust-project-goals/2026/afidt-box.html) | Medium | @nikomatsakis | RFC decision |
| [Implement Supertrait `auto impl`](https://rust-lang.github.io/rust-project-goals/2026/supertrait-auto-impl.html) | Medium | | Team aligned already on the... |
| [Nightly support for function overloading in FFI bindings](https://rust-lang.github.io/rust-project-goals/2026/overloading-for-ffi.html) | Medium | | Design meeting Experiment |
| [Rust for Linux in stable: language features](https://rust-lang.github.io/rust-project-goals/2026/Rust-for-Linux-language.html) | Medium | @joshtriplett | Reviews, Lang/RfL meetings |
| [Open Enums](https://rust-lang.github.io/rust-project-goals/2026/open-enums.html) | Medium | | Champion and (ideally) a la... |
| [Ergonomic ref-counting: Share trait and move expressions](https://rust-lang.github.io/rust-project-goals/2026/ergonomic-rc.html) | Medium | @nikomatsakis | |
| [Continue Experimentation with Pin Ergonomics](https://rust-lang.github.io/rust-project-goals/2026/pin-ergonomics.html) | Medium | @traviscross | Design meeting? |
| [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 | | Champion @joshtriplett |
| [Sized Hierarchy and Scalable Vectors](https://rust-lang.github.io/rust-project-goals/2026/scalable-vectors.html) | Medium | @nikomatsakis | RFC decision for [rfcs#3838... |
| [Stabilize cargo-script](https://rust-lang.github.io/rust-project-goals/2026/cargo-script.html) | Small | | Stabilization discussions |
| [Normative Documentation for Sound `unsafe` Rust](https://rust-lang.github.io/rust-project-goals/2026/safe-unsafe-for-safety-critical.html) | Small | | Feedback on language semant... |
| [Crate Slicing for Faster Fresh Builds](https://rust-lang.github.io/rust-project-goals/2026/crate-slicing.html) | Small | | Discussion on review of res... |
| [Wasm Components](https://rust-lang.github.io/rust-project-goals/2026/wasm-components.html) | Small | | Experimentation with native... |
| [Evolving the standard library API across editions](https://rust-lang.github.io/rust-project-goals/2026/library-api-evolution.html) | Small | | Review of the feature and l... |
| [MIR move elimination](https://rust-lang.github.io/rust-project-goals/2026/mir-move-elimination.html) | Small | @Amanieu | RFC decision |
| [C++/Rust Interop Problem Space Mapping](https://rust-lang.github.io/rust-project-goals/2026/interop-problem-map.html) | Small | @tmandry | Reviews |
| [BorrowSanitizer](https://rust-lang.github.io/rust-project-goals/2026/borrowsanitizer.html) | Vibes | @tmandry | Champion: @tmandry. General... |

## Summary by champion

| Champion | Goal | Level |
| :------- | :--- | :---- |
| @Amanieu | [MIR move elimination](https://rust-lang.github.io/rust-project-goals/2026/mir-move-elimination.html) | Small |
| @joshtriplett | [Rust for Linux in stable: language features](https://rust-lang.github.io/rust-project-goals/2026/Rust-for-Linux-language.html) | Medium |
| @nikomatsakis | [Const Generics](https://rust-lang.github.io/rust-project-goals/2026/const-generics.html) | Large |
| | [Stabilize Return Type Notation](https://rust-lang.github.io/rust-project-goals/2026/rtn.html) | Large |
| | [Stabilize the next-generation trait solver](https://rust-lang.github.io/rust-project-goals/2026/next-solver.html) | Medium |
| | [Box notation for dyn async trait](https://rust-lang.github.io/rust-project-goals/2026/afidt-box.html) | Medium |
| | [Ergonomic ref-counting: Share trait and move expressions](https://rust-lang.github.io/rust-project-goals/2026/ergonomic-rc.html) | Medium |
| | [Sized Hierarchy and Scalable Vectors](https://rust-lang.github.io/rust-project-goals/2026/scalable-vectors.html) | Medium |
| @scottmcm | [reflection and comptime](https://rust-lang.github.io/rust-project-goals/2026/reflection-and-comptime.html) | Large |
| @tmandry | [Field Projections](https://rust-lang.github.io/rust-project-goals/2026/field-projections.html) | Large |
| | [Reborrow traits](https://rust-lang.github.io/rust-project-goals/2026/reborrow-traits.html) | Medium |
| | [C++/Rust Interop Problem Space Mapping](https://rust-lang.github.io/rust-project-goals/2026/interop-problem-map.html) | Small |
| | [BorrowSanitizer](https://rust-lang.github.io/rust-project-goals/2026/borrowsanitizer.html) | Vibes |
| @traviscross | [Project goal - High-Level ML optimizations](https://rust-lang.github.io/rust-project-goals/2026/high-level-ml.html) | Medium |
| | [Continue Experimentation with Pin Ergonomics](https://rust-lang.github.io/rust-project-goals/2026/pin-ergonomics.html) | Medium |
| (no champion) | [Redesigning `super let`: Flexible Temporary Lifetime Extension](https://rust-lang.github.io/rust-project-goals/2026/redesigning-super-let.html) | Large |
| | [Immobile types and guaranteed destructors](https://rust-lang.github.io/rust-project-goals/2026/move-trait.html) | Large |
| | [In-place initialization](https://rust-lang.github.io/rust-project-goals/2026/in-place-init.html) | Medium |
| | [Experiment and RFC for `#[manually_drop]`](https://rust-lang.github.io/rust-project-goals/2026/manually-drop-attr.html) | Medium |
| | [Implement Supertrait `auto impl`](https://rust-lang.github.io/rust-project-goals/2026/supertrait-auto-impl.html) | Medium |
| | [Nightly support for function overloading in FFI bindings](https://rust-lang.github.io/rust-project-goals/2026/overloading-for-ffi.html) | Medium |
| | [Open Enums](https://rust-lang.github.io/rust-project-goals/2026/open-enums.html) | Medium |
| | [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 |
| | [Stabilize cargo-script](https://rust-lang.github.io/rust-project-goals/2026/cargo-script.html) | Small |
| | [Normative Documentation for Sound `unsafe` Rust](https://rust-lang.github.io/rust-project-goals/2026/safe-unsafe-for-safety-critical.html) | Small |
| | [Crate Slicing for Faster Fresh Builds](https://rust-lang.github.io/rust-project-goals/2026/crate-slicing.html) | Small |
| | [Wasm Components](https://rust-lang.github.io/rust-project-goals/2026/wasm-components.html) | Small |
| | [Evolving the standard library API across editions](https://rust-lang.github.io/rust-project-goals/2026/library-api-evolution.html) | Small |

## Goal details

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

**Point of contact:** @oli-obk

**Champion:** @scottmcm

**Support level:** Large

**Notes:** Design meeting, experiment

> Finish the implemented reflection scheme based on `const fn` that can only be called at compile time.
> Valdiate it against existing reflection libraries by giving them a nightly feature that obsoletes having derives and makes the derives no-ops.
> Obtain T-lang and T-libs-api buy-in for the scheme and write an RFC.
> This proposal is solely for producing const eval values, not for putting types back into the type system.
> That will be a follow-up once this proposal has a merged MVP.

**Comments:**

(space for team discussion)

Josh (no discussion needed): +1, and would champion if it didn't already have one.

nikomatsakis (no discussion needed): +1, though I'm not sure if this seems large, will we be accepting the RFC this year?

TC: Let's do it. Would champion also.

Jack: +1, but doesn't feel large; feels "too early" to need lang team super involved (I don't think this will or should get to RFC this year)

Nadri: exciting stuff, +1 (does feel large to me, I expect design scope creep)

tmandry: sounds good

Jack: I get the feeling it shouldn't be large

Josh: It should be large if the proposer says it should be large.

Jack: What's the vibe we should be giving?

Josh: Either "yes, ship it" or "needs discussion"

Jack: If the scope for getting to RFC doesn't seems to be plausible, we should discuss

Josh: If you believe the scope is not realistic, flag it in the doc and we'll get to it

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

**Point of contact:** @BoxyUwU

**Champion:** @nikomatsakis

**Support level:** Large

**Notes:** Stabilization decisions, directional 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)

nikomatsakis: +1

Jack: +1, lots of work, some design meetings already, this is moving towards stabilization

Nadri: +1, also Boxy knows what she's doing so excited to see what she'll bring us

tmandry: What I'm not seeing is the one that I see people trying to use, `&str`.. are ADTs the wrong thing to prioritize?

TC: Aligned with what we had talked about in the last design meeting. Want more details about:

> Design and stabilization of min_generic_const_args is purely a types team affair.

I'd flag that for review.

Niko: Tyler's point is something Boxy and I can discuss

Josh: People want static string constants all the time, please flag it. I don't think ADTs are distraction but static strings are just as high a priority.

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

**Point of contact:** @BennoLossin

**Champion:** @tmandry

**Support level:** Large

**Notes:** Aiming for two design meetings; large language feature

> 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)

nikomatsakis: I think this might be nicely framed as the goal being a *design RFC*, true/false? The goal is to narrow down the set of routes but not necessarily do a detailed design

Nadri: what's a Design RFC?
Jack: agreed
Niko: https://rust-lang.zulipchat.com/#narrow/channel/213817-t-lang/topic/stages.20of.20development/with/571913742
tmandry: people working on it are aligned on direction
Nadri: seems like the right kind of thing yea

Josh (no discussion needed): +1, and would champion if it didn't already have one.

TC: +1; as alway, worth coordinating with the pin ergonomics work.

Jack: Curious why two design meetings are needed? Would be good to get to the "design RFC" that Niko pointed out. +1 on as a goal

Benno: The first is for getting a general vibe check on the solution, the second one is later in the process after compiler experimentation
Josh: 2 design meetings seem like a reasonable upper bound. We might not need both if we're perfectly aligned.
Jack: Feels like we should discuss in the context of the proposed process changes

Nadri: this is looking to be a huge feature with deep ramifications

Nadri: overall vibe: excited

### [Redesigning `super let`: Flexible Temporary Lifetime Extension](https://rust-lang.github.io/rust-project-goals/2026/redesigning-super-let.html)

**Point of contact:** @dianne

**Support level:** Large

**Notes:** Would need a design meeting and RFC review.

> I aim to meet with the language team to discuss redesigning the `super let` feature, write an RFC for it, and work towards stabilizing it.

**Comments:**

(space for team discussion)

Josh: This needs a champion. Looks good, though; ship it!

TC: I particularly expect to champion this one. Have been working with dianne on formalizing these matters.

Nadri: +1, cool design corner that would strengthen the language. also dianne has already been doing great work in this area so excited to keep making the language more consistent

nikomatsakis: I expect TC to champion this. Come on TC! (Oh, he volunteered now.)

scottmcm: we're using it in macros already; we should make it a real thing.

tmandry: Nothing particularly blocked on it but it's great to ship while we have an expert like Dianne who can drive discussion. Happy to see it.

Jack: looking forward to a "real design" to be proposed

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

**Point of contact:** @nikomatsakis

**Champion:** @nikomatsakis

**Support level:** Large

**Notes:** Stabilization decision

> 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)

nikomatsakis: Obvious caveat, assume that the new trait solver lands first.

TC: Ship it.

tmandry: We should ship it; it's a big gap.

Josh (asynchronous, does not need live discussion): Does the current plan for RTN have a solution for both "returned future should have this property" and "returned future's return value should have this property", separately? Or is that future work? If it's future work then +1, if the plan encompasses both then I anticipate lots of design discussion but still +1.

Jack: Are the current concerns from a types POV? Is it *design* work needed? Or impl work? Feels unfortunately "blocked" and not on t-lang.
Niko: RTN for trait methods is done from our POV, needs types sign-off only.
Niko: However, RTN does not cover async closures, that requires design work. I should make this clearer in the summary.

Nadri: gut-feel that I'm still not sure this is the thing we'd want in an ideal world. interaction with the effects features we've been dreaming about unclear. but realistically let's ignore that and move forward x)

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

**Point of contact:** @jackh726

**Support level:** Large

**Notes:** Design session needed to work through design

> 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)

Josh: This needs a champion. (Ah, looks like Jack is offering to champion.) Looks good to me, though; ship it! I want this, so very much. I think the scope seems reasonable given how far it does and doesn't propose to get.

nikomatsakis: I am very keen on this and want to help, but I'd rather not overextend myself champion wise. If we had no champion I'd drop someting to pick it up. Note that I exnteded the goal somewhat to cover more of the hierarchy.

tmandry: AIUI there's a huge gap in performance between Move and Forget because Move stops at pointer boundaries while Forget does not. So we should set expectations accordingly. (lcnr blog post about this.) That said, vibe is +100 I want these.

TC: Worth mentioning `Overwrite` in the same breath. Always felt we should come back to that.

Nadri: I think this would unblock a _lot_ of things, excited to see the design happen. large design space tho, will need a lot of input. interactions with `!Destruct`? `AsyncDrop`?

Jack: This got a name change, ooh. Obvs I'm champion so +1 from me. I don' think it gets to full RFC, but a Design RFC sounds sensible. I think this doent need teh whole lang team. I think Medium is better.

Mark: I remain pretty worried about this design space, but interested in seeing discussion continue.

Jack: this could make it to the design RFC phase.

Josh (async): I do think this needs "large", it's a major impact on the language and we need to understand it and give detailed directional feedback on the experiment so we reach the right design in the future.

Nadri: +1 on "large"

### [In-place initialization](https://rust-lang.github.io/rust-project-goals/2026/in-place-init.html)

**Point of contact:** @Darksonn

**Support level:** Medium

> Evaluate the different approaches to in-place initialization and, together with
> the lang team, align on a recommended approach.

**Comments:**

(space for team discussion)

Josh: Needs discussion because it has no champion listed; also, is this actually medium, or should it be large? But looks great otherwise, ship it!

scottmcm: feels large because the design space is super-big here, as seen by having so many different proposals already, so aligning sounds hard.

nikomatsakis: I think we can make the case for Large by saying: this Design RFC needs to be accepted. That's a team consensus. I'm def +1 on this. I think tmandry is champion? But I don't know.

TC: Looks good; thinking tmandry would take this.

Benno: My opinion is this should be large and is probably a good candidate for the Design RFC that Niko mentioned

Nadri: +1

Benno: We're still missing some work items/tasks, I recall a PR with that?
Niko: Maybe it didn't land?
Benno: I might've just suggested to add the details, but Alice might've forgotten to do so?

Jack: seems a bit sparse on details, but +1 on getting to design RFC

Tyler: I'll make sure this has a champion. Either me or Alice; Alice is eligible to self-champion.

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

**Point of contact:** @lcnr

**Champion:** @nikomatsakis

**Support level:** Medium

**Notes:** Stabilization decision for user facing changes

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

**Comments:**

(space for team discussion)

scottmcm: Yes please!

TC: Let's do it. I do expect there will be interesting lang things coming to us as it gets near, in terms of accepting remaining breakages.

Jack: Big +1, but pretty minor lang involvement, I think (tbh, I think lang could even just be "tagged" for the stabilization - I would expect type to be delegated and own this)
Niko: Yes, it might even be small.
Nadri: yea, what are the expected lang asks?
Josh: I think "medium" is a minimum, because it might end up needing careful review if there are effective semantic changes at merge time.
Nadri: I'd expect most consequences would be t-types stuff but I'm not involved in this

Nadri: ship itttt!!

Josh: 🚢🚢🚢🚢🚢

tmandry: Yes please; my feedback is "can we mark some of the blockers out of scope and ship ASAP" (thread: https://rust-lang.zulipchat.com/#narrow/channel/546987-project-goals.2F2026-workshop/topic/Next-gen.20trait.20solver.20goal)

Josh: have all the lang changes depending on this happened already or will there be changes at stabilization time?
Jack: There will be work on stabilization
TC: There will be breakages, yes
Josh: Then this should be medium

### [Project goal - High-Level ML optimizations](https://rust-lang.github.io/rust-project-goals/2026/high-level-ml.html)

**Point of contact:** @ZuseZ4

**Champion:** @traviscross

**Support level:** Medium

**Notes:** 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.

> Project goal - High-Level ML optimizations

**Comments:**

(space for team discussion)

nikomatsakis: needs a summary! but generally a big fan, this hasn't been any real skin off our backs so far, which is fine. ~~TC wll champion?~~

TC: I'm a champion for this. Exciting work. We're looking across project to see how we can support it better. Funding, getting people involved.

Jack: +1, think pretty minimal lang involvement at this stage

Josh: Seems reasonable in scope and goals as currently proposed (*not* expecting to reach stabilization). Exploring offload seems fine.

Josh: Flagging that this needs libs-api involvement for `std::offload` and isn't currently marked as such. Exact sizing for libs-api unclear and not for us to determine.

Nadri: meta point on whether this even needs a Goal, unclear what the scope is tbh
Niko: it is a message from us and it helps Manuel to get funding etc, plus TC is spending champion time so it's "team resources" if you will.
Nadri: makes sense, will keep in mind for the "what even are Goals" discussion
Josh: I like having explorations be goals, with appropriately sized team asks (explorations may often be as small as "vibes").
Nadri: no argument against explorations :+1:

tmandry: This reminds me of things like MPI(?) that are essentially language level extensions to C++. I think it is important work but also wonder how many of these we can/should accept into the language.

nikomatsakis: a question I'd like to put on the radar, how to do this in ways that doesn't require support.
TC: That's the point of the explorations. We're aligned on this.

### [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:** Medium

**Notes:** Vibe check and RFC review

> 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)

scottmcm: I ponder what the holistic philosophy should be around wrapper types vs attributes, though that's not really about the goal itself.

TC: Agree with scottmcm. Interesting exploration.

Jack: ehhhh, I haven't seen much discussion in this area; this feels even earlier in the process than prior-mentioned goals - feels right in scope (though, RFC -> design RFC)

Nadri: problem makes sense to me, fits in the "interop" flasgship theme (is that one? should be one). scope not super clear tho, not a fan of the proposed design

nikomatsakis: I'm in favor of exploring, as long as we really have the bandwidth; that's my concern. Who will champion?
niko: IS the goal not having an RFC?
tyler: It seems like a small thing to me

tmandry: I will champion if no one else wants it

Josh: "reach an RFC" seems reasonable, as long as the expectation isn't that we *merge* the RFC.

Alice: every time I've proposed things like this (`#[align]` or `#[pin]` on fields), the feedback was it should be a container not attribute. I like attributes though.

Jack: Meta: There are competing design directions.

Nadri: yea I proposed an alternative solution, see here: https://rust-lang.zulipchat.com/#narrow/channel/213817-t-lang/topic/Opinions.3A.20.60.23.5Bmanually_drop.5D.60.20vs.20.60Drop.3A.3Adrop_in_place.60/with/571949492

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

**Point of contact:** @aapoalas

**Champion:** @tmandry

**Support level:** Medium

**Notes:** Continued experiment support, design feedback

> Bring the `Reborrow` and `CoerceShared` trait to nightly Rust, enabling iteration based on user feedback. Begin work on nontrivial cases where more than one lifetime is being reborrowed or coerced into shared

**Comments:**

(space for team discussion)

scottmcm: feels like a critical part of doing `&mut`-like custom receivers, so experimentation makes lots of sense to me.

TC: Let's explore it; as mentioned in the goal, let's keep talking between this and the pin ergnomics work.

nikomatsakis: tmandry mentioned the possibility of a "quick win" here where we stabilize the *use* of these traits for `Pin` but not the traits themselves, I really like that idea (maybe other places too?).

Josh: I think this is simpler than it initially sounds, and seems fine.

Nadri: I think this is deeper than it initially sounds ^^, excited to see the design work on this.

Jack: Good scope - does need types (and probably libs-api) added

Alice: Previously brought up in `CoerceUnsized`. There was a `Pin<&mut T>` coercing to `Pin<&T>`.
Tyler: that's probably right. If we have a general mechanism, we have to find a way to integrate shared coercions with the borrow checker.

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

**Point of contact:** @nikomatsakis

**Champion:** @nikomatsakis

**Support level:** Medium

**Notes:** RFC decision

> Introduce `.box` notation and use it to enable dyn dispatch for traits with async methods. The initial scope is `foo.method().box` where `method()` returns a dyn-compatible RPITIT. In the future `.box` could be used more generally but before expanding it we would like to see progress on the work towards [in-place initialization](./in-place-init.md).

**Comments:**

(space for team discussion)

Josh: +1 for this goal, I'm excited to see this. This seems directionally correct and I don't anticipate having concerns with it.

tmandry: The interesting question for me will be how much uptake this gets vs people continuing to use `#[async_trait]` because of ergonomic cost at the call site. I don't know of a way to run this experiment without shipping the feature. I like the idea of "making the explicit ergonomic" and I think we need to see how it plays out in practice.

TC: Compelling problem; I share some of the reservations Mark expressed elsewhere about the solution maybe being a bit special-purpose. Are there broader, more powerful mechanisms that would solve the problem? Worth exploration.

Jack: too early for RFC imo - needs some experimentation
- aside: curious that this is "Medium" for "RFC decision"
Nikomatsakis: Strong disagree, we've been discussing this for YEARS. I think getting to the point of an RFC this year (not stabilization) seems plausible. But I agree it is large. This is one that I think is ill-sized.
Nikomatsakis: Let me weaken my statement mildly, I guess I don't strong disagree, but I do want to lean in, because I feel we've stalled and there is urgency.
Jack: I guess, let's just get this implemented so we can start to actually talk about concrete semantics.
Nikomatsakis: when we're looking at the scope of work in a year, we should be asking "do you see a world where this can be done?" vs. "are you sure?". Is there a path where we'd say "this worked pretty well"

Mark: I'd be happy to dig in more with you on this (continuing that thread we had on Zulip around .box vs. other async features).

Nadri: +1 on "large", agree on the problem this aims to solve, would want to see how this fits into a coherent story with e.g. in-place init, custom pointers, custom allocators, etc etc (yea sorry for the scope creep. maybe "just do the simple thing" is what we need)

Benno: +1, very important to stay in contact with the in-place init stuff, but seems like that is sufficiently on people's radar.

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

**Point of contact:** @tmandry

**Support level:** Medium

**Notes:** Team aligned already on the shape of the feature

> Within the 2026 goal period we strive for completion of the following items.
> - Implementation of the core language features stipulated by the RFC 3851. See rust-lang/rfcs#3851.
> - Continuous update on the RFC for errata to reflect necessary changes as implementation moves along.
> - Resolve the `impl` overlapping question, possibly as an optional feature behind an associated feature gate.
> - Field trial of the standard library trait refactoring with the `supertrait_auto_impl` feature gate.
> - Implementation of the optional features and lints spelled in the RFC as much as possible.

**Comments:**

(space for team discussion)

nikomatsakis: does this solve the Service/Send tower example? It looks like it might
Tyler: Good question, I'd have to think about

nikomatsakis: TL;DR I strongly want it and I am concerned about finding the best champion

scottmcm: Still a big fan of the meta-goal of allowing semver-compatible trait refactoring. No strong feelings on the details of this goal text specifically.

tmandry: I want this badly. I should probably not be point of contact, heh, but am willing to champion.

Josh: libs-api really really wants this. I think keeping it to "medium" will require aggressively managing the scope, but I think there's a well-scoped version of this that will work as "medium" and will solve the problems people want it to solve.

TC: Important problem; let's see where it goes.

Jack: Happy to see impl work done here, scope is appropriate

Nadri: would unblock cool things, looking forward

TC: Is Ding working on this?

Alice: I assume he is but I don't know teh status

Tyler: He's still working on it. Mostly blocked on reviews

Alice: re point of contact, that should probabyl be Ding

Tyler: I agree

### [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

**Support level:** Medium

**Notes:** Design meeting Experiment

> 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)

scottmcm: Colour me skeptical, but that doesn't need to block exploring it. I don't think "for FFI" is really a reflection of the scope of this, and ad-hoc unprincipled overloading has more downsides than I think this is acknowledging. If it was just `unsafe extern "C++" { ... }` that might be one thing, but it's not.

TC: +1 to scottmcm's points.

Jack: "ok" - feels like we need a lang "vibe check" on this before we commit to an experiement

Nadri: important for interop, we need this in some way; worried about scope creep

Alice: In principle we can pass variable number of parameters to printf. This seems similar to that for C++ overloading. but this could easily scope creep to "we have overloading for all Rust"

Josh (no sync discussion needed): Have discussed with tmandry async, +1 for the scope and direction as specified. Would like to see the goal include more of the rationale discussed. I think Tyler's plan avoids scope creep.

tmandry: Look at the design axioms. I think we have a path forward to not reaching for this in normal Rust

Josh: We have a champion (Tyler), metadata needs fixing

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

**Point of contact:** @tomassedovic

**Champion:** @joshtriplett

**Support level:** Medium

**Notes:** Reviews, Lang/RfL meetings

> Continue working towards Rust for Linux on stable. In particular, this goal is focused on the language features.

**Comments:**

(space for team discussion)

Jack: Are there things in here that could need a lang design meeting? Medium feels small for the number of things here (though, admittedly, a lot of these are far in the process)

nikomatsakis: as a meta note, I feel like I'd rather have goals for the features and a 'theme' of RFL, like a flagship theme.
Niko: this was a holdover from the first round of Project goals and a theme made more sense. I think it's fine to have a goal for the process, but it could be implied by people championing individual project
Niko: We should have a flagship theme to support low level systems and Rust for Linux in particular
Tomas: Given CPython interest, having a broader "low level systems" theme makes sense to me
Josh: More prominent projcets: git, systemd etc. We should have a process taht scales beyond "let's make a meeting for every new project"

Nadri: seems to depend on a lot of existing goals/initiatives. yea like Niko said this may be a theme rather than a goal. e.g. could want arbitrary_self_types as a separate goals

scottmcm: I don't like the title. RFL is an important customer, but that's not necessarily a *goal* scope.

Josh: Each individual item feels "medium" but I think the amalgamation of *all* of them together is not "medium". I think this might be "large".

Alice: The goal is "stabilize things for Rust for Linux".

scottmcm: It makes it a random grab-bag is my objection. Goals for features would make me happier.

TC: There's an aspect of this about process. Continuing the effort, meetings.

Mark: no_fp_fmt_parse stabilization feels unlikely/premature given overlap with build-std, unless we have some special casing (not sure it's warranted).

Josh: As written this is Large, not a Medium. We could make it a large goal or medium goals part of a flagship team.

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

**Point of contact:** @kupiakos

**Support level:** Medium

**Notes:** Champion and (ideally) a lang meeting

> 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)

scottmcm: I have concerns about the phrasings and solutions, but not actually about the problem space.

Nadri: same as scott. would want to consider pattern types in this, and the exhaustiveness implications of not giving a name to the variant

Jack: hard to commit to a project goal when there hasn't been much discussion - but a year is a long time

nikomatsakis: I wasn't really aware of this but I'm in avor of making progress on it based on what I have heard about its applications.

Alice: I totally want this for things I'm working on! I'm willing to champion.

Josh: Willing to champion this if it doesn't have a champion or we need to rebalance.

tmandry: I want this. I think it's a nice solution. Don't understand the feedback on the RFC that it shouldn't be an enum.

Alice: This would solve a lot of problems. Being able to define an enum with a few constents but not being UB accessing other constants is imporant. For Linux but I ran into it in other systems

tmandry: also important for a protocol you want to evolve for ABI. Anything related to ABI stability needs something like this

TC: Interesting problem; will need exploration to build confidence around a particular solution.

### [Ergonomic ref-counting: Share trait and move expressions](https://rust-lang.github.io/rust-project-goals/2026/ergonomic-rc.html)

**Point of contact:** @nikomatsakis

**Champion:** @nikomatsakis

**Support level:** Medium

> Implement and prototype two foundational improvements for ergonomic ref-counting: (1) a `Share` trait that semantically identifies types where cloning creates an alias to the same underlying value, and (2) move expressions (`move($expr)`) that allow precise control over what closures capture and when. These changes lay groundwork for future ergonomic improvements while delivering immediate value, with prototypes targeted for summer 2026.

**Comments:**

(space for team discussion)

Jack: curious where explicit closure captures went (oh that's the move expressions)

Nadri: might be good for a Design RFC, there have been a lot of proposals in the space. Need to see the whole picture before I feel confident in merging a part. EDIT: these two specific features actually look fine on their own

Josh: if this is an experiment, +1; if this is "merge the RFC", I think this will take design meetings and will end up being "large". (For move expressions specifically, not Share).

TC: Probably I'm more onboard with `move` than with `Share`.

scottmcm: That's not what I would expect "move expressions" to do by their name, but the problem space +1. (Aside: to me, a move expression would be something that forces a `Copy` type to move, rather than copy, which would reduce stack pressure.)

tmandry: I'm interested. Unsure about the specifics. I think move expressions seem quite nice. I like the name share.

Niko: I want this merged and stabilized

Josh: Then this is large. But I want to see it, let's do it.

Mark: Is Share actually T-lang if we don't have .use or similar?

Josh: I think `Share` is lang because we anticipate building on it, but in theory it'd be just libs-api if there was no proposed lang feature.

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

**Point of contact:** @frank-king

**Champion:** @traviscross

**Support level:** Medium

**Notes:** Design meeting?

> Continue experimenting with and fleshing out the design and semantics for the pin ergonomics experiment.

**Comments:**

(space for team discussion)

Jack: continued experimentation here feels appropriate

nikomatsakis: I have no idea what's going on here =) well, I do remember reading updates. But is there anything we think we can get to stabilize over the next year? It seems hard to believe we can't do anything. If nothing else, the interaction with reborrow would be a small but distinctly noteable win.

Alice: What is the relationship to `!Move`?

tmandry: I think we need to flag that the `Move` goal proposal proposed itself as an alternative to this work.

Nadri: still waiting to see a fleshed out proposal for this. also Field Projections will likely make a lot of this obsolete.

Alice: are we going to have two goals solving the same problem in two ways?

Josh: Experimentation is good. In addition to the two goal both proposing to solve this,

TC: There's other related goals: auto reborrow, field projections

Josh: The work Yosh proposed too

TC: I don't think they're actually conflicting. Pin ergonomics is a natural expension of what's here today.

Josh: There are four different things proposing to solve the same problem let's make sure they're aligned

TC: yes

### [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

**Support level:** Medium

**Notes:** Champion @joshtriplett

> 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: somehow I ended up as POC on this one, I feel like lang involvement is probably low (maybe review of early drafts of (experimental) reference text)

nikomatsakis: What do you expect from lang here, Josh? I would like to see lang champions being responsible to author changes to the reference, as TC has suggested from time to time. (Or at least 'on the hook', they can delegate.) I would prob call that "large".

Josh: I expect this to be some combination of "lang" and "spec", but it's something that involves lang processes which is why I think we need lang alignment.

TC: This is a fork of the Reference. It's friendly in that we're all interested in seeing experimentation. I do think that lang-docs should be on this at least in terms of an ask for assurances of deeconfliction.

Josh: Confirming that my understanding is that this is a friendly fork, and is intended to be amicable.

tmandry: This is an experiment for processes to put things into the reference. How are we going to get feedback on the final stage of actually merging things into the reference?

Nadri: very excited for this, this is a process point that's been holding us back for a long time

Josh: This is not a redesign applying to all teams at this time. It's a case study with Types team of N=1 and look at the result. It involves managing a separate repository acting as though it would be upstream. But it's not to successfully merge them into the reference. It's an experimental process. In particular, this doesn't change the requirements to stabilize; we have a process to stabilize and that won't change during this experiment, someone wanting to stabilize still has to get something into the reference.

Jack: The plan is to keep it up-to-date with the Reference. Regular (not necessarily daily) syncs

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

**Point of contact:** @davidtwco

**Champion:** @nikomatsakis

**Support level:** Medium

**Notes:** RFC decision for [rfcs#3838], stabilization sign-off

> 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)

scottmcm: looking forward to seeing it land; I think it'll open a bunch of interesting new other things too (extern types, different ways of arranging box, ...)

TC: One of the main things left to work out, I think, is how we treat the transitiveness of bounds relaxation and whether we want syntactic markers for that.

Jack: is this "Large" because of stabilization, +1 generally though
nikomatsakis: yes, my bad.

Josh: Ship it. This will need team consensus because stabilization, but I think it'll be straightforward, there's been a lot of groundwork here.

Nadri: would unblock a lot, +1

tmandry: I really want to see it. It didn't seem to make much progress in the last cycle so I'm wondering if that's predictive of this cycle and if there's something we can do to help unblock.

Niko: It made progress but not around Sized Hierarchy. Everyone's waiting on everyone, I want to stop that.

Josh: There are things that are stabilization where we're checking boxes and there are ones with complex designs. Saying "stabilization automatically means Large" feels like it's missing nuance between different sizes of stabilizations.

Tyler: This is an RFC plus stabilization

Josh: Fair, then it's totally large.

### [Stabilize cargo-script](https://rust-lang.github.io/rust-project-goals/2026/cargo-script.html)

**Point of contact:** @epage

**Support level:** Small

**Notes:** Stabilization discussions

> Stabilize support for "cargo script", the ability to have a single file that contains both Rust code and a `Cargo.toml`.

**Comments:**

(space for team discussion)

Jack: This probably is happening *soon*, so +1

nikomatsakis: :rocket:

Nadri: :passenger_ship:

Josh: 🚢, and I think we've unblocked everything now.

tmandry: Ship it.

TC: Frontmatter is now in FCP. There was one more lang-related thing: our jurisdiction around stability implications. At some point cargo-script proposed having a floating edition (it'd always use the latest). We need to check that from the lang policy.

Josh: This is support level medium, then. That needs at least a brief discussion.

Jack: I could see this wrapped before the project goals are even accepted. We'll see.

nikomatsakis (not for discussion): (I wouldn't object to requiring explicit edition, I don't .. think?)
Nadri: was gonna propose this
Josh: Would prefer not to have to have a full frontmatter block for that, but in principle would love to have a trivial solution there.
niko: I imagined like `---2025` or `#!/bin/foo ~~ 2025` or something
Josh: Niko, unfortunately that's hard because of limitations on shebangs. We should talk async.

### [Normative Documentation for Sound `unsafe` Rust](https://rust-lang.github.io/rust-project-goals/2026/safe-unsafe-for-safety-critical.html)

**Point of contact:** @PLeVasseur

**Support level:** Small

**Notes:** Feedback on language semantics questions as needed

> The Safety-Critical Rust Consortium will investigate real-world safety-critical codebases to identify common `unsafe` patterns, then work with t-opsem to create normative documentation in the Rust Reference and standard library docs.

**Comments:**

(space for team discussion)

scottmcm: Feels hard to scope without knowing how gnarly the found patterns end up being 😬

Jack: Seems fine, given lang is just "give some feedback as it comes up"

nikomatsakis: +1, not really on us tho (but it is just small)

TC: I'd champion this one; RalfJ's an advisor, so theoretically he could take it directly as well.

Nadri: looking forward to writing down a lot of things that live in "tribal knowledge" today. mostly t-opsem anyway

Josh: This is appropriate scope for lang. It ended up being adjusted for libs-api

tmandry: Not a big support from us (hopefully). It might end up being a series of small things that together add up to a larger thing.

Josh: Scopes can be normative statements of what we are prepared to do. We could say we allow for a small support level and if it's more, then that's as much as we can do.

nikomatsakis: I think we have to encourage opsem to take more ownership (and resolve the structural issues that prevent it if we can, e.g. bandwidth)

Josh: huge +1 on delegating more with written guidelines

TC: I'd be willing to champion from the Lang side

Josh: It's "small" so it doesn't need a champion

### [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:** Discussion on review of research methodology and findings

> 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)

scottmcm: How much of this needs to be lang? Could this be entirely compiler+cargo and lang doesn't change anything?

Jack: Yeah, not sure there is lang anything here

nikomatsakis: I am very interested in the work this person is doing but I do not yet have any confidence that the work they are doing is in any shape that could be upstreamed. Regardless I think it is basically not lang.

Josh: I'm interested as well. I don't *think* it's lang, more compiler and cargo and similar. But I observe that it's essentially proposing an experiment, so I think we move ourselves to "vibes" and wave it onwards.

Nadri: seems far-away from getting into the compiler proper, let alone lang implications imo

tmandry: Mostly not lang, but to take the other side, I think it would benefit lang to understand how the emergent properties of the language results in a poor user experience on build speed.

Josh: This is an experiment, let's do vibes and and let the experiemnt proceed

Jack: Agreed, vibes

Tyler: the goal has a lang ask "Discussion on review of research methodology and findings"

Jack: That's a good point

Josh: Good point. That's less an ask of us and more an offer to us to have the discussion and give us data that supports us. We should encourage that!

### [Wasm Components](https://rust-lang.github.io/rust-project-goals/2026/wasm-components.html)

**Point of contact:** @yoshuawuyts

**Support level:** Small

**Notes:** Experimentation with native Wasm features will need approval. May become "medium" if we are somehow really successful.

> In 2026 we want to improve the state of Wasm Component support in Rust. This
> means adding and stabilizing three new compiler targets, as well as begin
> experimentation with Wasm-specific language features.

**Comments:**

nikomatsakis: Love me some wasm.

Jack: +1, small scope, minimal overhead from lang

Josh: Sounds reasonable. Because this is an experiment, I think the ask is reasonable. I'd also love to volunteer to help advise here, not as champion since it doesn't need one but I can assist. Want to see more native support for wasm that doesn't require external tools.

Mark: I don't understand what's lang here. Experiment with #[repr(wasm)] and extern "wasm" seems like the only thing... but that is aspirational?

tmandry: Don't see anything objectionable (basically the things Mark mentioned.. seem fine)

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

**Point of contact:** @Amanieu

**Support level:** Small

**Notes:** Review of the feature and lang implications.

> Add a mechanism for edition-dependent re-exports which allows the standard library to make larger API changes across editions.

**Comments:**

nikomatsakis: We gotta extend the blessings of editions to stdlib! And we need this for ranges. Let's do it!

Jack: +1

Nadri: +1

Josh: +1, and with my libs-api hat on, this is very high priority for libs-api. libs-api is essentially counting on this happening and assuming it will; we've shipped things on the assumption it will.

TC: Glad to see this happy. Happy to champion, including from the Edition team side.

tmandry: How do we raise the petrochenkov bat signal? I want to see it; we should support libs-api in evolving std.
Mark: +1, seems like lang-simple but compiler-hard.

### [MIR move elimination](https://rust-lang.github.io/rust-project-goals/2026/mir-move-elimination.html)

**Point of contact:** @Amanieu

**Champion:** @Amanieu

**Support level:** Small

**Notes:** RFC decision

> Add a MIR optimization which eliminates move operations. This will require changes to the MIR semantics of `move` to enable the optimization to cases where a value has had its address taken (LLVM already eliminates moves when this is not the case).

**Comments:**

(space for team discussion)

scottmcm: Very much interested in this -- understanding what a `move` in MIR actually does unblocks so many important things -- but unsure whether "small" reflects the complexity of determining what the semantics ought to be that enable the desirable transforms. Unless it's small for lang but bigger for some subteam?

Nadri: would expect that this is largely t-opsem. they've been having a lot of that discussion already

nikomatsakis: in favor, have to figure out compiler champion, but that's not the problem here.

Jack: Is this just an *optimization*, or are there lang guarantees?

Nadri: it needs semantics changes/decisions, which is probably more t-opsem than lang but pretty sure we'll want to commit to them

Josh: I really want to see this. Agreed that it's small for lang and larger for opsem. Is there some way we can give a lang-level "we want this" as guidance to opsem?

Tyler: Does this need a Lang RFC as we're introducing new kind of behavior?

Niko: More like leveraging things that are UB now

Josh: If there was anyone counting on unwritten rules on the language, they may be surprised

Niko: I think it's much more opsem than lang

Nadri: They've been having that conversation for a long time

Josh: Agreed it's small for lang and more for opsem. But there's value to give opsem from lang to show how valuable this is. Many things in lang don't take the idea that moves can be expensive into consideration that much.

### [C++/Rust Interop Problem Space Mapping](https://rust-lang.github.io/rust-project-goals/2026/interop-problem-map.html)

**Point of contact:** @baumanj

**Champion:** @tmandry

**Support level:** Small

**Notes:** Reviews

> Document a set of technical issues related to C++/Rust interoperability with broad community consensus to serve as a starting point for proposed solutions and facilitating cooperation among stakeholders in both language communities.

**Comments:**

nikomatsakis: *mostly* in favor? I think? I'm not 100% sure what I'm agreeing to *as a lang team member*. But I want interop!

Jack: So...I *want* this to be something that can be Medium/Large support - Foundation is a hiring a contractor, and I'm hoping this could maybe result in e.g. design meetings or vibes about interop problems/solutions. I'd like to see discussion with lang on those solutions. As written the goal is not what I expect to come out of it

Tyler: I largely agree. There is work happening on solutions (e.g. beyond refs benefits interop). It would be great if we had someone who's hammering away on "smaller problems". There's discussion about having north star RFCs. We did a design meeting about interop last year. I'm interested in taking that doc and turning it into a North Star RFC

Josh: +1, I feel like the discussion as proposed is fine but also please please do *much more* and start doing actual experiments sooner.
- Jack: yep, that's getting pushed to the staff by the PDs
- Josh: I'd like to see an additional goal written up that's medium/large for the more ambitious work

Nadri: looks like the ask is "finding community consensus on problems"? happy for this to happen and to stay informed of how it evolves tho

tmandry: Also not sure if there's a lang ask beyond "vibes".

### [BorrowSanitizer](https://rust-lang.github.io/rust-project-goals/2026/borrowsanitizer.html)

**Point of contact:** @icmccorm

**Champion:** @tmandry

**Support level:** Vibes

**Notes:** Champion: @tmandry. General support and guidance.

> We are building BorrowSanitizer: an LLVM-based instrumentation tool for finding violations of Rust's aliasing model. In 2026, we want to make it feature-complete and useful in practice.

**Comments:**

nikomatsakis: in favor but...this seems just opsem + compiler.

Jack: vibes scope, this is good

Nadri: exciting work, don't see the lang ask

tmandry: Love it.

Josh: a champion is listed, but it's vibes-level, not needed a champion

Niko: you can have a champion for smaller things, it's not required

Josh: Could this be relevant for more than Rust?

TC: Is this operating on LLVM?

Tyler: It's operating on LLVM IR

Josh: If that works as anticipated, please reach out if this needs a blog post extolling its virtues

Nadri: FYI this exists and works today

Josh: That's why I'm so excited. We should promote the hell out of this.

TC: It doesn't work until it's shipped with rustup and put in people's hands.

---

TC: what are the next steps? Niko, Tyler?

Tyler: the Project goals team needs to shuttle feedback back to owners. I can help. And for Niko and I to make a pass and look at the sizes. And then further pass at doing capacity planning.

Niko: I agree. We can expect to get a revised draft pretty quickly. Then I want to have you all looking at it again.

TC: In terms of this meeting, do you think this was useful?

Niko: I was super happy.

The room: Thanks TC for pushing this through.

Josh: Niko, reach out to me re goals, I could help. Also, I plan to put in a goal re macro expansion rule. I'm happy to self-champion it, does anyone have objections to a late entry? Continuing the previous macro work (attributes, derives, syntactic improvements)

Tyler: No objections. Who would implement it?

Josh: I'm planning on implementing it.