Immobile types and guaranteed destructors

[tomassedovic]

Metadata
Point of contact	@lcnr
Team(s)	lang, types
Goal document	2026/move-trait

Summary

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, 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.

Tasks and status

---

Note: we have updated the body to match the 2026 goal. Your original text is preserved below.

Details

Metadata
Point of contact	@lcnr
Team(s)	lang, types
Goal document	2026/move-trait

Summary

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, 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.

Tasks and status

[tomassedovic]

This issue is intended for status updates only.

For general questions or comments, please contact the owner(s) directly.

[jackh726]

There was a discussion about default auto traits at the All Hands (rust-lang/all-hands-2026#28)

There's also a zulip stream: https://rust-lang.zulipchat.com/#narrow/channel/549962-t-lang.2Fmove-trait

[lcnr]

Not much work has happened directly for this feature. We're slowly moving an nightly support for Move forward in rust-lang/rust#156018. The main difficulty here is adding support for this trait without causing regressions for stable code.

@jdonszelmann is looking into changing the representation of ParamEnv to reduce the performance impact of adding new implicit default trait bounds. Improving performance when new where-clauses are in scope and these bounds have to be proven everywhere is essential, as without them we get an up to 7400% compile-time performance regression in our performance suite. I am confident that we can reduce this to a more acceptable level.

We also need to make sure adding these new bounds does not cause breaking changes and enable library authors to remove these implicitly added bounds over time. New types which don't implement Move can otherwise not be used with large parts of the ecosystem. This is why I've started working towards new language features to enable users to migrate off these default bounds by creating a new Library Trait Evolution Initiative.

@lqd has been working to support weakening errors involving generic parameters to a FCW, see my blogpost for an overview of this feature. This is also important for #270.