--- title: rust-project-goals/src/2026/move-trait.md at main ·... description: A Rust project goal (2026-2027) proposes introducing new traits — `Move`, `Destruct`, and `Forget` — to make type capabilities explicit rather than assumed.... canonical: https://daily.dev/posts/rust-project-goals-src-2026-move-trait-md-at-main-rust-lang-rust-project-goals-3tvgmuaya twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: rust-project-goals/src/2026/move-trait.md at main · rust-lang/rust-project-goals | daily.dev og:description: A Rust project goal (2026-2027) proposes introducing new traits — `Move`, `Destruct`, and `Forget` — to make type capabilities explicit rather than assumed.... og:url: https://daily.dev/posts/rust-project-goals-src-2026-move-trait-md-at-main-rust-lang-rust-project-goals-3tvgmuaya og:image: https://api.daily.dev/og/posts/3TvGMUAyA.png og:image:alt: rust-project-goals/src/2026/move-trait.md at main · rust-lang/rust-project-goals og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # rust-project-goals/src/2026/move-trait.md at main · rust-lang/rust-project-goals **[Hacker News](https://daily.dev/sources/hn)** · 6 min read · 2 upvotes · 0 comments ## Summary A Rust project goal (2026-2027) proposes introducing new traits — `Move`, `Destruct`, and `Forget` — to make type capabilities explicit rather than assumed. Currently Rust assumes all types can be relocated in memory and forgotten via `mem::forget`. The new traits would allow types to opt out: `!Move` types maintain a stable address (replacing the need for `Pin`), and `!Forget` types guarantee their destructors run, enabling safe scoped spawn for async. This is positioned as an alternative to Pin ergonomics improvements, with the eventual goal of deprecating `Pin` entirely. The work mirrors the Sized hierarchy approach and will be validated in the Linux kernel. Changing the `Future` trait is explicitly out of scope. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Community take How the wider developer community reacted, aggregated from 1 discussion and 69 comments across hackernews (as of 2026-08-03). **TL;DR:** The Hacker News community is broadly enthusiastic about adding immovable types (!Move) and must-move/linear types (!Forget/!Destruct) to Rust, seeing them as filling a long-standing gap and enabling structured async concurrency and safer API designs, though there is significant discussion about backwards compatibility challenges and the relationship to the existing Pin mechanism. **Sentiment:** 60% positive · 30% mixed · 10% skeptical **The case for** - Linear/must-move types would enable APIs (e.g. transactions) that force callers to explicitly commit or rollback, catching errors at compile time. - Immovable types would allow safe self-referential structs and enable structured async concurrency (scoped tasks) without unsafe code. - The proposal is more principled than the existing Pin hack, potentially eliminating the need for duplicated Trait/PinnedTrait variants. - Rust editions provide a migration lever to manage backwards compatibility concerns. **The pushback** - Backwards compatibility is a serious concern: all existing Rust code assumes any type can be dropped/moved freely, and changing defaults could break the vast majority of existing code. - Integration with standard library traits (e.g. Iterator::Item, Deref::Target) is non-trivial and could require pervasive ?Move bounds throughout the ecosystem. - The relationship and migration path from the existing Pin/Unpin mechanism is unclear and potentially complex. - This is only an accepted project goal, not a finalized language change — the design may change significantly or be abandoned. **By community** - hackernews (positive): Commenters are largely enthusiastic and technically engaged, welcoming the proposal as addressing a long-standing gap in Rust, while raising substantive concerns about backwards compatibility and Pin integration. **Hottest debate:** Whether and how immovable types can be added without breaking the vast majority of existing Rust code, particularly around standard library traits like Iterator and Deref. **Open questions** - How will !Move types interact with existing Pin usage and pin projection? - How should standard library collections like Vec handle !Move element types? - Can the backwards compatibility problem be solved cleanly via editions without requiring pervasive ?Move annotations throughout existing code? - How does !Forget interact with reference cycles (e.g. Rc/Arc) and cross-thread ownership transfer? **Highlights** > For context, the reason this would be really nice is that it would enable API designs that catch certain kinds of errors. let txn = create_transaction(); // do something with the transaction txn.commit(); // consume the txn Right now, you can't implement this API without choosing between either silently rolling back unless the user calls `commit()`, or panicking in the Drop impl for the transaction if the user didn't explicitly call either `commit()` or `rollback()`. Your only current choice is to use closures, which are much less composable, because you need a variant for each flavor: infallible, fallible, async fallibe, etc. start_transaction_async(async || { /* ... */ TransactionResult::Commit }); start_transaction_async_try(async || { /* ... */ Ok(TransactionResult::Commit }); Ick. If instead the transaction is a must-move type, you would get a compiler error if you fail to call exactly one of either commit or rollback, and particularly you would be forced to consider what happens at every exit point (early-out via `?` no longer just forgets the transaction). Very nice. > — [simonask on hackernews · 1 comments](https://news.ycombinator.com/item?id=49152854) > The big one is scoped tasks, or structured concurrency. Currently, Rust has scoped threads: Threads that are guaranteed to terminate before the function that spawned them returns. This is powerful because it allows you to pass references to data that lives on your own stack to threads that you spawn, without any bookkeeping or synchronization mechanism - just the normal borrow checker rules. For example, you can allocate a large array, then split it into multiple non-overlapping slices, and then have a group of threads populate each slice, all in safe Rust code. But the same isn't true for async tasks in Rust, because futures are just objects representing a state machine, and they don't get any special treatment. In particular, they carry no guarantee that the state machine will actually run to completion, which is fundamentally different from how functions run (stack frames are guaranteed to unwind in some way, either by returning or panicking, unless the entire program has terminated). To make the situation worse, there are many cases where Rust futures are much more prone to cancellation than synchronous code, because that is also one of the big benefits of using async in the first place - for example, you may be running multiple futures in parallel, pick the result from the one that finishes first, and then cancel the rest. Getting this stuff under control is why people say that "async cancellation" is a difficult problem to solve, and that is true in all languages that have async. These traits will hopefully make it much easier to work with in Rust. (There are also many other interesting things you could do with this, unrelated to async. Immovable and unforgettable are both interesting properties of an object that could be used to design many cool APIs in general.) > — [simonask on hackernews](https://news.ycombinator.com/item?id=49152333) > None. The question is more what happens when you put a `!Move` type into, say, `Vec`, because that's a collection type that regularly moves its elements to a new allocation when it grows or shrinks. Should it be possible to construct a `Vec` whose size can never change? Is there a subset of Vec's API that can be annotated with `where T: ?Move`? These are all important design questions, with the potential to break 99% of existing Rust code. > — [simonask on hackernews](https://news.ycombinator.com/item?id=49154818) > Ok, I guess somebody has to provide the youngsters/uninitiated with some context. What is going on here can be viewed as part of a process of Rust (potentially) incrementally adopting the C++ model, because the Rust model is limited in important ways. Specifically, Rust's "necessarily-trivial-destructive" moves make it possible for a memory location previously holding a valid object to become invalid without a destructor (or any other handler) being called. Accommodating this possibility resulted in unforeseen (by many) limitations, particularly in the safe subset. (See "the leakpocalypse".) This was partially addressed by the introduction of "pinning" into the Rust language. The posted github page suggests that this sort of pinning is not the ideal approach, and that it is more effective to make the "unmovability" of an object a property of the object's type, rather than a property of the reference to the object, as is the case with the pinning approach. To be clear, we're talking about Rust-style "necessarily-trivial-destructive" movability here. Traditionally, C++ doesn't really support this sort of movability. That is, even if an object's contents are ("conceptually") moved to a different location, the original source object remains (at its original location) until it is otherwise destroyed (and its destructor called). So in C++, all types are "immovable" in the sense of the posted github page. The github page notes how these "immovable" types can support self-references completely in the safe subset in a way that pinning can't. > This unblocks patterns that are currently impossible in safe Rust. For an idea of some other unblocked patterns, you can consider so-called "norad" pointers [1] (and proxy pointers [2]) in the SaferCPlusPlus library. Analogous to how `RefCell` references can be used to express references that cannot be statically verified to conform to Rust's "aliasing-xor-mutability" restrictions, "norad" pointers can be used to express references that cannot be statically verified to be lifetime safe. This would include, for example, all manner of cyclic references beyond just "self-references". I think you could implement a version of these norad pointers in Rust that can safely target these immovable types (whose destructor is guaranteed to be called while the object is still in its original location). But note that the C++ implementation uses static inheritance (which Rust does not support) to avoid the noise having to access the target object as "interior" content (like with `RefCell`s). With the availability of these flexible references, one could imagine immovable types becoming popular in things like games / entity component systems, GUI frameworks, browser engines, and any place where "back pointers" would be convenient. One might even imagine that at some point, types being "immovable" could become the popular default for object types in Rust (among biological and/or non-biological Rust programmers). At which point, people may decide that actually they do want (the contents of) some of their immovable types to be "movable", but they don't necessarily need the object to be destructively movable. So you could imagine the introduction of standard `nondestructive_move()` (and `nondestructive_move_from()`) methods that would be companions of the existing `clone()` (and `clone_from()`) methods. At which point Rust would have counterparts for C++ copy and move constructors (and assignment operators). In my view, this adoption of the C++ model (potentially) addresses Rust's main limitation. With one consequence being to potentially make automated translation of C and C++ code to (reasonable code in) the safe subset of Rust much more feasible than seems to be currently. [1] https://github.com/duneroadrunner/SaferCPlusPlus/blob/master... [2] https://github.com/duneroadrunner/SaferCPlusPlus/blob/master... > — [safercplusplus on hackernews · 1 comments](https://news.ycombinator.com/item?id=49154882) > The compat issue has always been associated types on std traits. For example, should Iterator::Item be Move or ?Move If you leave it as Move, you can't create any iterators over !Move types. If you change it to ?Move, then functions using generic iterators can't assume that the elements of an Iterator are always moveable. Which is a breaking change compared to now. The most critical trait is probably Deref. Using !Move types without `Deref::Target: ?Move` is painful, because calling any method on boxed types relies on Deref. > — [Dagonfly on hackernews](https://news.ycombinator.com/item?id=49156186) **Source threads** - [hackernews](https://news.ycombinator.com/item?id=49152023) · 64 points · 69 comments ## Similar posts on daily.dev - [Move, Destruct, Forget, and Rust · baby steps](https://daily.dev/posts/move-destruct-forget-and-rust-baby-steps-xwxiulp3v) · Lobsters · 14 upvotes · 1 comments - [a grand vision for rust](https://daily.dev/posts/a-grand-vision-for-rust-fnxjbzooa) · Lobsters · 0 upvotes · 0 comments - [Project goals for 2025H2](https://daily.dev/posts/project-goals-for-2025h2-uqr9pvuzp) · Rust · 8 upvotes · 1 comments - [Async Rust: Pinning demystified](https://daily.dev/posts/async-rust-pinning-demystified-rfgkmdeya) · The New Stack · 2 upvotes · 0 comments - [11 year old unsoundness bugs found in Rust borrow checker](https://daily.dev/posts/11-year-old-unsoundness-bugs-found-in-rust-borrow-checker-lhmassetq) · Hacker News · 0 upvotes · 0 comments --- Tags: [#rust](https://daily.dev/tags/rust) [View this post on daily.dev](https://daily.dev/posts/rust-project-goals-src-2026-move-trait-md-at-main-rust-lang-rust-project-goals-3tvgmuaya) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"rust-project-goals/src/2026/move-trait.md at main · rust-lang/rust-project-goals","url":"https://daily.dev/posts/rust-project-goals-src-2026-move-trait-md-at-main-rust-lang-rust-project-goals-3tvgmuaya","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/rust-project-goals-src-2026-move-trait-md-at-main-rust-lang-rust-project-goals-3tvgmuaya"},"datePublished":"2026-08-03T08:07:39.462Z","dateModified":"2026-08-03T14:27:46.631Z","description":"A Rust project goal (2026-2027) proposes introducing new traits — `Move`, `Destruct`, and `Forget` — to make type capabilities explicit rather than assumed....","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/101db48519bcaed72f087a304a3a33f1?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/101db48519bcaed72f087a304a3a33f1?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Hacker News","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Hacker News","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1/logos/hn","url":"https://daily.dev/sources/hn"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/rust-project-goals-src-2026-move-trait-md-at-main-rust-lang-rust-project-goals-3tvgmuaya","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":2},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"rust","timeRequired":"PT6M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Hacker News","item":"https://daily.dev/sources/hn"},{"@type":"ListItem","position":3,"name":"rust-project-goals/src/2026/move-trait.md at main · rust-lang/rust-project-goals"}]} ```