Tracking issue: `Move` trait

[yoshuawuyts]

This is a tracking issue for experimental work related to the Move auto trait.
The feature gate for the issue is TODO.

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.
Discussion comments will get marked as off-topic or deleted.
Repeated discussions on the tracking issue may lead to the tracking issue getting locked.

Background

We’d like to propose an experiment for a new trait auto-trait Move that determines whether a type can be freely moved around or must keep a stable memory location. This is intended to be a safe and simple language-level alternative to the existing pinning system. At the heart of this is a new auto-trait Move with default bounds:

#[lang = "default_trait"]
unsafe auto trait Move {}

By default all types implement Move which enables them to change memory locations, which is how Rust behaves today. But if a type chooses to implement !Move, the compiler will guarantee that that type will have a stable location in memory until it is has finished dropping.

This work will initially only focus on introducing the Move trait and enabling the compiler to enforce those checks. We’re intentionally not (yet) focusing on backwards-compatibility with existing traits, migrating existing uses of Pin, or more advanced features like move-constructors.

@lcnr and I recently ran an experiment for this in the compiler, proving that this work should be feasible. We were initially quite concerned with potential performance regressions, but on further investigation we determined this should be manageable.

Relationship to other experiments

In-place initialization

This work compliments Project Goal 2025H2: In-place initialization, which enables types to be constructed in a stable memory location. This makes it possible to return !Move types directly from constructors without needing to copy data, which is done by writing data to an out-pointer rather than being copied out of a function.

Pin ergonomics

This work is an alternative to Project Goal 2025H2: Continue Experimentation with Pin Ergonomics, which includes the following extensions:

• A new item kind pin in lvalues, e.g. &pin x, &pin mut x, &pin const x.
• A one-off overload of Rust’s Drop trait, e.g. fn drop(&pin mut self).
• A new item kind pin in patterns, e.g. &pin <pat>.

We will refrain from litigating the differences between proposals here. But suffice to say: we are aware of this proposal and we believe that Move is the better direction. We’re filing for a lang experiment so we can prove this by implementing it.

Further Reading

• Ergonomic Self-Referential Types > Immovable Types Yosh Wuyts, 2024
• Adding implicit auto-trait bounds is hard lcnr, 2025
• Move trait perf test #146201 lcnr, 2025
• Initial support for auto traits with default bounds #120706 Bryanskiy, 2024
• Project Goal 2025H2: In-place initialization Alice Ryhl, 2025

Contacts

Some relevant contacts:

• Design: @yoshuawuyts
• Implementation: @nia-e, @lcnr
• Compiler team liaison/reviewer: @lcnr
• Lang liaison: @jackh726

Steps

• Approve as lang experiment.
• Implement in nightly.
• Accept an RFC.
• Add documentation to the dev guide.
  • See the instructions.
• Add documentation to the reference.
  • See the instructions.
• Add formatting for new syntax to the style guide.
  • See the nightly style procedure.
• Stabilize.
  • See the instructions.

Unresolved Questions

Implementation History

[traviscross]

We reviewed this in the lang call today for context. Thanks @yoshuawuyts for pushing forward on this experiment. @jackh726, in his role as a lang-advisor, volunteered to champion this.

[scottmcm]

There's a bunch of stuff around here like how to mix opt-outs with the direction away from ?Sized in the sized trait hierarchy, and all the previous looks at this wanted to not do that because of other complications like how to deal with them in associated types.

But happy to have the experiment go ahead and see where it ends up!