Skip to content

Experiment proposal: Move auto-trait #354

@yoshuawuyts

Description

@yoshuawuyts

Experiment: Move auto-trait

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

Contacts

Some relevant contacts:

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions