AINEWS
The popular systems programming language is rewriting how its compiler reasons about memory, with the Linux kernel port as the test case.
In Rust today, every value is assumed to be movable. The compiler can copy a struct, shuffle it across an array, or hand it to another function, and the programmer is expected to make sure the move is legal. That assumption breaks in two places: self-referential async futures, which hold pointers into their own data, and the kinds of types the Linux kernel needs to keep pinned in place and clean up reliably when a scope exits.
A 2026 Rust project goal, accepted this year and running through 2027, tries to fix both by making immovability and guaranteed destruction properties of the type itself. The proposal introduces three new traits, applied automatically by the compiler, called Move, Destruct, and Forget. Types can use these to opt out of being relocated, implicitly dropped, or hidden from the destructor system. The first two are positive capabilities layered over a base layer, following the same pattern as the existing Sized marker that already lets a type say whether its size is known at compile time.
A self-referential async future stores a pointer to its own buffer; move it and the pointer dangles. Today, Rust encodes that constraint with Pin, a wrapper that says "this value lives in this place and stays there" rather than "this type cannot be moved." Async libraries like tokio have to thread Pin through every layer that touches a future, and the language team has spent years documenting the [Pin-projection problem](https://blog.yoshuawuyts.com/self-referential-types/): the headache of pulling fields out of a pinned future without breaking the immobility guarantee. Language designer Niko Matsakis has written about the deeper issue, that Pin papers over a type-system gap rather than expressing the constraint natively.
The second anchor is the kernel. The Rust for Linux project has been merging Rust code into the kernel for years, and kernel types face constraints ordinary Rust code does not: no allocator assumptions, no panicking destructors in some paths, types that must run their cleanup logic at scope exit without being skipped. The current safety net is a convention, not a guarantee. The standard mem::forget function, which silently throws a value away without running its cleanup code, is safe in Rust today. The project goal is to make destructor-skipping a type-level decision, not a programmer-discipline one.
Mechanically, the design follows the existing Sized precedent. A base trait covers the default case (a type is movable and has a destructor); specialized auto-applied traits opt out of the default, with negative implementations (a reversed version that says a type explicitly does not satisfy the trait) for types like &mut T that should not be movable across the boundary. That mirrors how ?Sized already works and gives the compiler enough information to reject code that moves an immobile type, just as it rejects code that moves a &mut reference.
The goal document names "Rust for Linux" as a roadmap mapping entry alongside "Just add async," and the team will write RFCs and ship Minimum Viable Product (MVP) compiler support as the work progresses. The tracking issue on rust-lang/rust lists the feature gate as TODO; no compiler work has landed under the new framing yet, and the project-goal tracker shows the goal in its 2026-2027 window. The champions are @lcnr on the types side and @jackh726 on the language side, with discussion on Zulip in the #t-lang/move-trait stream.
The trade-off is the part the roadmap page does not lead with. Capability traits add a new axis to the type system; every type now has a position on a multi-way matrix (movable, destructible, forgettable, generic-friendly), and the language team has been explicit that this is exploratory. A Hacker News thread on the goal page surfaced the same tension: a commenter pointed out that project-goal acceptance is a commitment to do the work, not a final design, and others flagged that the kernel's ABI constraints can still reshape the proposal before any of it ships. Skeptics inside and outside the language team have asked whether the complexity is worth it when scoped handles, ownership refinements, or a narrower scoped-spawn primitive for async tasks that must finish before their parent returns could solve the destructor case without a full capability-trait system.
What is settled: the direction. Rust is moving immovability and guaranteed destruction from wrappers and conventions into the type system itself, with the kernel as the load-bearing test case. What is not: the trait names, the precise opt-out surface, the timeline for any compiler MVP, and whether the kernel port will accept the design as written or push it toward something smaller. The 2026-2027 window is the window in which those answers get written.