Immobile types and guaranteed destructors

[tomassedovic]

Metadata
Contact	@lcnr
Team(s)	lang (@jackh726), types (@lcnr)
Goal document	2026/move-trait
Funding contact	Funding team

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.

---

This issue is intended for status updates only.

For general questions or comments, please contact a goal owner or post in the Zulip topic.

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

[lcnr]

@zannabianca1997 has taken over the work on landing Move on nightly in rust-lang/rust#161457. The current plan is to have all crates add the implicit Move bound, even if they don't implement the feature, so that crates who enable feature(move_trait) don't get unsoundness bugs when by using dependencies which should require T: Move.

Having these where-bounds everywhere required a bunch of minor fixes to printing and symbol mangling. Unfortunately, even when automatically considering Move to hold when the feature is not enabled, we still get an up to 5% performance regression when compiling diesel.

Separately @jdonszelmann has continued to look into improving the representation of ParamEnvs. This requires a lot of data collection as it's somewhat unintuitive what's actually perf-sensitive when dealing with ParamEnvs.