Rust wants to get rid of Pin: immovable types and guaranteed destructors

The Rust project has approved a goal for 2026–2027, authored by a developer under the handle @lcnr. It concerns a fundamental assumption built into the language from the very start: any value can be relocated in memory and “forgotten” via mem::forget without running its destructor. Both assumptions are baked into the semantics — assignment moves values, and mem::forget is considered a safe operation. For some types, however, these abilities are nothing but a hindrance.

Why it's needed

The first case is immovable types. Many async futures are self-referential by nature, and such structures cannot be moved safely. Today the problem is solved by Pin, which encodes immovability as a property of a place rather than of a type. The authors call this outright a source of excess complexity, one that is especially painful in the Linux kernel.

The second case is guaranteed destructors. A Transaction type may require a call to commit() or rollback() before it is destroyed, and the handle of a time-bounded task must wait for the task to complete. But because mem::forget is safe, the language cannot guarantee that the destructor will run.

What is proposed

Instead of patches, new auto traits are being introduced that describe the capabilities of a type. The wording is deliberately positive — a trait denotes the presence of an ability:

• Move — the type can be relocated in memory;
• Destruct — the destructor runs when the value goes out of scope;
• Forget — the type can be forgotten without running its destructor.

This approach mirrors the logic of the work on the Sized hierarchy, which relaxed the rule that “the size of every type is known at compile time.” Types marked !Move are required to keep a stable address for their entire lifetime — which is simpler than Pin, because immovability becomes a property of the type itself. And !Forget opens the way to safe scoped spawn: the handle's destructor is guaranteed to wait for the task, so it cannot outlive the scope and reach into dangling references.

Plans and boundaries

Over the course of a year the team intends to implement an MVP in the compiler, write an RFC, and verify the idea's viability on real Linux kernel code, where self-referential structures are especially plentiful. @BennoLossin is taking on the testing.

The authors' distant goal is to abandon Pin entirely. The reasoning is this: since Rust promises eternal backward compatibility, making pin a language construct on par with & and mut means supporting it forever. That is why Move is presented not as a supplement to the experiments on Pin ergonomics, but as their direct alternative.

Everything concerning the Future trait — the only stable trait that depends on Pin — has been deliberately left outside the scope of the year. Reworking it will be pursued as a separate project, since the dependency on Pin is far from its only problem.

Source: Hacker News