Repository navigation
Immobile types and guaranteed destructors #635
Description
| Metadata | |
|---|---|
| Contact | @lcnr |
| Team(s) | lang (@jackh726), types (@lcnr) |
| 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.
This issue is intended for status updates only.
For general questions or comments, please contact a goal owner or post in the Zulip topic.
Activity
tomassedovic commentedon May 5, 2026
This issue is intended for status updates only.
For general questions or comments, please contact the owner(s) directly.
jackh726 commentedon Jun 2, 2026
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 commentedon Jul 31, 2026
Not much work has happened directly for this feature. We're slowly moving an nightly support for
Moveforward 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
ParamEnvto 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
Movecan 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 commentedon Sep 3, 2026
@zannabianca1997 has taken over the work on landing
Moveon nightly in rust-lang/rust#161457. The current plan is to have all crates add the implicitMovebound, even if they don't implement the feature, so that crates who enablefeature(move_trait)don't get unsoundness bugs when by using dependencies which should requireT: Move.Having these where-bounds everywhere required a bunch of minor fixes to printing and symbol mangling. Unfortunately, even when automatically considering
Moveto hold when the feature is not enabled, we still get an up to 5% performance regression when compilingdiesel.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 withParamEnvs.