For everybody who doesn't have the context, just note that this is not an accepted langauge change. It's a just project goal, which means it's accepted as something people will work on, but the design might change significantly or it can even be abandoned completely (which is pretty unlikely for this one, to be fair).
I think it's absolutely amazing to have insight into long-term goals like this for open source projects. For one thing, it can help you plan your tech stack, and can even be a source of inspiration on what sorts of topics to learn and what sorts of research to do.
If anything, pin ergonomics is at greater risk. People still discuss if we need both, but if we don't, then we go for this goal and not pin ergonomics, as it's more general.
It is at a greater risk because it is a very pervasive and complicated change, and the expected semantics are not fully understood. It might be that there is no way to do this well.
Great new! Since 2016 or so it became apparent that immovable types were a crucial missing part of Rust, but for a long time it was believed it wouldn't be possible to add them without breaking everything, which is why we ended up with the Pin hack.
I'm very glad they found a way to add it eventually, as it's really filling a glaring hole in the language.
They recognize that there's going to have to be some kind of compatibility or migration story for existing APIs based on Pin, but have decided to punt that question to next year. For now, the focus is on the non-async-related use cases for these new language features (for which Pin is already insufficient); once those are known to work, then they'll shift focus to letting the async ecosystem benefit too.
I don't see why it may fail to integrate. Declare Pin as !Move and... thats all? I mean, there will be issues, edge-cases because it is just how these things happen, but still I don't see any fundamental issues with continuing to use Pin.
Like others said, Pin is incompatible with these semantics. Some people argue, though, that we need both (basically because pinned types can be moved before being pinned).
> the point of Pin is to wrap types that CAN move.
I would highlight that there are many cases where you CAN move an object safely until a certain operation requires the object to "stay put" in place.
Pin allows for that by tying the object to the place only when required. That's why Pin relates to both the object and the place.
Meanwhile, !Move types can't ever move. The object has to remain in the inital place it was constructed in. !Move requires in-place construction and emplacement to be ergonomic at all.
> I would highlight that there are many cases where you CAN move an object safely until a certain operation requires the object to "stay put" in place.
You could model this with a state machine enum where the "stay put" phase is a variant that accepts a !Move, like so:
Stupid question, can't this trivially be solved by having a movable constructor / builder type that then gets turned into a non-movable type when built?
Sure, thats one reason why IntoFuture and Future exist. Imo, in hindsight this is also main mistake in aysnc Rust: The whole async system should be build around IntoFuture rather than Future (async fn should return impl IntoFuture).
That way you could pass around IntoFutures without being affected by auto traits leaking. Only when you actually call .await() or .poll() would the immovable Future materialize.
I guess `!Move` is largely equivalent to `Unpin` for the purposes of `Pin`, so for example Pin's safe constructor `Pin::new()` can be re-expressed in terms of `!Move` instead of `Unpin`. Today you need unsafe code to pin a `!Unpin` (i.e. "movable") type.
But I also suspect there are important differences between `!Move` and `Unpin` that I'm not sure about.
This whole thread summarizes what's wrong with Pin: it's so confusing everyone in here got something wrong. (Just to address your mistake in particular Unpin is almost the opposite of !Move: it's the trait that represents things that can be un-pinned, that is: moved despite having been pinned. See https://doc.rust-lang.org/std/pin/index.html#unpin).
> # How does this relate to the "pin ergonomics" initiative?
> This work is an alternative to Project Goal 2025H2: Continue Experimentation with Pin Ergonomics, which includes the following extensions:
> A new item family 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>.
> Notably, this work does not solve pin's duplicate definition problem, meaning that even with these extentions we still end up with Trait and PinnedTrait variants of existing traits. The Drop trait being the exception to this, since the initiative is proposing to special-case it using a one-off overload.
Although not part of the goal, it also mentions `!Destruct`/"must-move types", aka linear types: Instead of there always being a way to drop values without providing any arguments, if you wanna get rid of a value of a linear type you have to call a function that takes it by value.
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.
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.
Yes, destructuring is typically the only allowed way to get rid of linear/indestructible values. If the type has private fields, this is only possible in the same module, so commit(txn) and rollback(txn) would have to be implemented in the same module as the Transaction type.
Linear types requires significant work to incorporate into the core built-in collections and types. I've been following the work on Mojo to enable Linear type support for built-in types and collections, I don't think Rust's language semantics will allow for the same level of integration (Rust is already stable).
Yes, editions are a great mechanism. It still has its limits, especially if you want easy edition migrations. All existing Rust code assumes it can drop any type whenever it wants, and that is not something you can just change across editions. You have to be very careful with defaults if you don't want conflicts when crossing edition boundaries.
The naïve idea would be to just say that all generic parameters have an implicit `where T: Move` bound, and you have to explicitly opt out of it with `where T: ?Move`, just like with `?Sized`.
In fact, that's exactly how I would expect it to work, but there may be non-obvious drawbacks.
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.
The people working on this are aware that it poses backcompat problems that don't have obvious solutions. They are looking into non-obvious solutions. https://lcnr.de/blog/2025/11/28/implicit-auto-traits-assoc-t... is the most up-to-date one I'm currently aware of.
I'm very probably missing something, but as a user I would definitely expect `Iterator::Item: Move`, but then also that `&{mut} T: Move where T: ?Move`.
But yeah I can see how these bounds are somewhat viral. Thanks!
Imagine if MyTrait comes from core/std. Adding an opt-out bound like ?Sized (or ?Move) is a breaking change for any generic code that relies on Sized/Move. But you want some traits from std to be open for !Move types.
None. The question is more what happens when you put a `!Move` type into, say, `Vec<T>`, 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<T>` 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.
How so? This feel distinct from the "algebraic effects"-like features like constness, async, can-panic, can-unwind, etc., since this is a property of the types themselves rather than of functions.
The traits are essentially effect handlers for effects like `drop<T>`, `move<T>`, `forget<T>` which are implicitly charged to the a function which owns a `T` and does drops, moves, or forgets it.
Inferring the capabilities of the function from the traits of the types of the arguments is similar to tracking effects. The function charges `drop<T>` when `x: T` goes out of scope, which is handled by the trait implementation. If Rust had a proper algebraic effects type system, you would be able to see this directly in the signature of the function (and even more, if the trait impls themselves had their effects tracked, you'd be able to see from the signature of the function the side effects of deallocation of its owned variables, like if `drop<File>` performs `io`).
Yeah I should have phrased that better. The traits themselves are not the effects, they're bits of code which can have side effects. Rust doesn't track those side effects in the type system yet, but !Forget especially is the essence of that idea. If you implement it for everything owned by a function, you can basically infer that the function does not have the leak effect (which would be an effect in the effect row of a Forget trait implementstjon).
If you try treat memory as an effect you gain the need for several polymorphic effect type functions drop, forget, etc which map a type to the effect row charged by its corresponding Drop, Forget impl. Rust doesn't have that type system obviously.
The combination of exceptions and non-trivial {copy constructor, assignment operator, destructor} are what combine to make C++ a somewhat broken language when you try to use all the features. And also responsible for poisoning the well for exceptions as an error handling mechanism for native code.
Very similar to Windows Structured Exception Handling, which the Win32 implementation used, and also looks similar to Java, but without checked exceptions. try/except/end and try/finally/end blocks.
The major differences with C++:
* objects are references not values, cutting out all the copy constructor,
assignment operator, destruction on out of scope etc.
* objects are zero-initialized after allocation and before constructors run
* constructors are run from most derived to least derived
* calling Free method checks if Self is nil
* this + zero init means that you can call '.Free' on all the objects you
reference in the destructor without checking if they're nil first,
handling partial construction
It's not a memory safe language, but it does give you a bunch of idioms that, if you stick to them, you don't feel nearly as much pain as C++.
Does anyone know if there is any plan for no-panic to be a language feature? I think there was some discussion about this regarding Rust in the Linux kernel or embedded Rust but I don't know if there is any consensus or any plan regarding this.
This is not currently a project goal. As with many things in the Rust project, it could be, if someone wanted to step up and dedicate the required engineering resources.
mem::forget isn’t the only way you can safely leak a value, you can do it with reference cycles too, right? And there is no way for the compiler to detect that?
Isn’t that why mem::forget is safe, because you can always implement it yourself safely? How do you get around that?
> mem::forget isn’t the only way you can safely leak a value, you can do it with reference cycles too, right? And there is no way for the compiler to detect that?
But there's an easy solution for that: you make the reference-counted smart pointers require their pointee type to be Forget. It will be like how Arc<T> doesn't implement Send unless <T: Sync>.
The more accurate definition of `!Forget`, similar to `Pin<&mut !Unpin>`, is not "can be leaked" but "if the underlying storage is reused, the destructor is guaranteed to run". This enables all important (decidable - preventing leaking is undecidable, even in GC languages) use-cases, and sending the value to a thread does not break this contract.
Passing ownership to another thread is not the same as forgetting/leaking.
The point of !Forget is ensuring that once the owner goes out of scope the destructor must be guaranteed to run. An infinite loop is not a problem, cause the new thread will never leave its scope. Ref-cycles are a problem, cause you can create a ref-cycle. Then the program flow leaves the scope which will run the drop on all RC's but not the drop on the inner type.
> An alternative way to "forget" a value is to hand it off to another thread that then loops infinitely.
Might be able to address that by only allowing such a handoff to a thread spawned via some scoped abstraction to ensure that progress can only be made if/when the spawned thread terminates?
By doing the same as with `Sized`: Automatically including the `Forget` bound on generic parameters and letting methods that don't need to be able to forget them opt out. That way existing code continues to compile and existing unsafe code doesn't become unsound.
This was my first question too, I don't see anything addressing e.g. the cyclical arc example from the original 'spawn' conversation.
It seems like you have to auto-propagate !Forget, and then make 'anything that be used to logically implement forget', probably most importantly things like Rc take a Forget bound and do it at an edition boundary? But the link mentions none of that...
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.
I agree with most of that, but there's one important detail (that I'm sure the designers of this proposal are thinking about): The current contract of Pin in Rust (the only standard support for expressing immobility) doesn't just cover the object's own location, but also any references derived from the object, commonly called "pin projection".
For example, if you have a `Pin<Box<Vec<u8>>>`, it's safe to turn that into a `Pin<&mut [u8]>`.
Any system that replaces `Pin` will probably have to maintain that same property, which wouldn't naïvely happen using C++-like move semantics, right? Or maybe I'm overassuming?
Hmm, I'm not sure if you're concerned about the "norad"-style run-time checked references I'm imagining or raw references. In either case, the property we (and `Pin<>`) are concerned about is whether an object can be (destructively) moved. You're pointing out a reference derived from a pinning reference essentially inheriting the pinning property. (I.e. the property that the target won't be inappropriately (destructively) moved.)
But with this proposal, the property that the object won't be (destructively) moved is (solely) a property of the object's type. Specifically, it doesn't depend on any property of any reference to the object, and certainly not on any other reference that that reference was derived from, right?
> Any system that replaces `Pin` will probably have to maintain that same property
Maybe any system that compatibly replaces `Pin`. Maybe. But I'm not sure that this proposal is overly concerned with compatibility with `Pin`. That github page explicitly mentions the desire to deprecate `Pin`, right? And like I suggested, if successful enough, it's conceivable that it could end up de facto deprecating Rust's necessarily-trivial-destructive moves in general. Conceivably.
My sense of sentiment in the project right now is that people want to keep the invariant that assignment (to an ordinary memory location) is always just a memcpy and never calls arbitrary user-defined code, because if that code does something unexpected, debugging (at least if a human's doing it) is likely to be hampered by the syntactic invisibility of the call site. This is why the most obvious ergonomic-reference-counting proposal (have a trait that lets types opt into implicit clones) ran aground, and they're now experimenting with (conceptually clunkier, in my opinion) alternatives that aim to make reference counting ergonomic but still syntactically visible.
So if Rust ever gains move constructors, you'll probably have to call them explicitly, the way you have to explicitly call .clone(). (There's actually already a third-party library that does something like this (https://docs.rs/moveit), and I think Crubit is using a similar API to let Rust code call C++ move constructors.)
One of the main reasons Rust needs this capability is because C++ has it, and Rust wants to interop with it. It's not that better model (enabling it additionally can bring benefits, but also complications; enabling it by default, like C++ does, is a terrible idea).
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.)
It doesn't really add anything new and flashy, but removes some annoying warts.
Sync code has scoped threads that enable multi-threaded execution within a function, without having to ensure the data outlives the function call. Async can't do that while guaranteeing safety. This makes tokio::spawn awkward and annoying, and is a major source why people dislike Rust's async.
Low-level async code that polls Futures requires using the Pin wrapper type, which is unergonomic, and doesn't really guarantee safety, but it's more like a "be careful here" sign. Proposed changes would make that code look more like normal Rust and work without unsafe escape hatches.
> and is a major source why people dislike Rust's async
It's worth mentioning that there is, in fact, no language out there other than Rust that can even do this in the first place.
Some languages give the illusion that they support it by boxing the stack frame of async functions and letting a garbage collector deal with the consequences, but that comes with significant drawbacks too (additional GC pressure, heap allocation overhead, requiring a GC in the first place).
You can do it with C++ coroutines, but it's much harder to do correctly than in Rust if you want to maintain any sense of conviction that the system is correct.
The main reason that structured async concurrency would be so awesome to have is that it feels like Rust has the right set of features that could enable it with a set of constraints that are so much more attractive than any other language out there can provide - no overhead, "just works" with no drawbacks.
(For the record, you can actually get pretty far today using primitives like `FuturesUnordered` instead of `tokio::spawn` and similar, but this sidesteps the runtime's scheduler, so YMMV. This basically creates a task-local mini-scheduler for your futures, which may or may not be sufficient.)
Wait, how does it actually change the recursive async story?
The problem today is that the compiler-synthesized struct implementing `Future` for each async function cannot contain an instance of itself without boxing, because it would create a type of infinite size. That's a separate problem that's also hard to solve nicely, because the call tree might be deep, and deciding where to cut (using Box::pin) is non-trivial.
Little by little, Rust, like D, acknowledges that C++ flexibility regarding object construction, copy and move, even if too much as a default, is sometimes needed :)
For what it's worth Ada currently has RFCs for constructors in destructors closer to the C++ way. They're currently supported in the GNAT (GCC Ada) compiler.
I guess the point is that the concepts are needed, which is true. But the Rust way (more explicit and targeted) of dealing with these concepts seems better than how either C++ or D handle it.
D is my favorite language that I wish I could use more, but the chances of me being paid to use it are too low, I wish that job market would expand, I feel like D needs a really good alternative to Vibe.d a web framework with a well designed ORM, or a rich GUI stack out of the box. Go became massive because a production ready but simple HTTP server came out of the box, and other nice to haves that made being productive in Go a breeze from day 1.
I also like d a lot even if I did not use it that much (toolchain and getting things done problems mostly, besides not great platform support).
The metaprogramming of D is really impressive.
In fact I considered using Vibe.d for some backend: it has fibers. I love stackful coros in general (virtual threads in Java, for example). Way more than stackless for most uses.
But I am afraid that Vibe.d could not be flexible enough. With Java, Python, etc. I have more than enough for my needs right now.
To be clear, this is absolutely not adding any sort of C++-style overrideable implicit move or copy constructor to Rust. There's not really any relationship to C++ in this proposal, it's just a step towards opt-in linear types.
For everybody who doesn't have the context, just note that this is not an accepted langauge change. It's a just project goal, which means it's accepted as something people will work on, but the design might change significantly or it can even be abandoned completely (which is pretty unlikely for this one, to be fair).
I think it's absolutely amazing to have insight into long-term goals like this for open source projects. For one thing, it can help you plan your tech stack, and can even be a source of inspiration on what sorts of topics to learn and what sorts of research to do.
I think this one might be at greater risk than usual of being dropped, because it's explicitly mutually exclusive with another accepted project goal (pin ergonomics): https://github.com/rust-lang/rust-project-goals/blob/main/sr...
If anything, pin ergonomics is at greater risk. People still discuss if we need both, but if we don't, then we go for this goal and not pin ergonomics, as it's more general.
It is at a greater risk because it is a very pervasive and complicated change, and the expected semantics are not fully understood. It might be that there is no way to do this well.
Great new! Since 2016 or so it became apparent that immovable types were a crucial missing part of Rust, but for a long time it was believed it wouldn't be possible to add them without breaking everything, which is why we ended up with the Pin hack.
I'm very glad they found a way to add it eventually, as it's really filling a glaring hole in the language.
> I'm very glad they found a way to add it eventually
Will this integrate with existing code that uses Pin<T>? If not this will split the ecosystem even further...
They recognize that there's going to have to be some kind of compatibility or migration story for existing APIs based on Pin, but have decided to punt that question to next year. For now, the focus is on the non-async-related use cases for these new language features (for which Pin is already insufficient); once those are known to work, then they'll shift focus to letting the async ecosystem benefit too.
I don't see why it may fail to integrate. Declare Pin as !Move and... thats all? I mean, there will be issues, edge-cases because it is just how these things happen, but still I don't see any fundamental issues with continuing to use Pin.
Like others said, Pin is incompatible with these semantics. Some people argue, though, that we need both (basically because pinned types can be moved before being pinned).
Pin applies to the pointer, !Move applies to the pointee.
So... Pin should be defined as Pin<T: !Move>?
No, the point of Pin is to wrap types that CAN move. If the type were !Move then Pin wouldn't be needed.
> the point of Pin is to wrap types that CAN move.
I would highlight that there are many cases where you CAN move an object safely until a certain operation requires the object to "stay put" in place.
Pin allows for that by tying the object to the place only when required. That's why Pin relates to both the object and the place.
Meanwhile, !Move types can't ever move. The object has to remain in the inital place it was constructed in. !Move requires in-place construction and emplacement to be ergonomic at all.
> I would highlight that there are many cases where you CAN move an object safely until a certain operation requires the object to "stay put" in place.
You could model this with a state machine enum where the "stay put" phase is a variant that accepts a !Move, like so:
Stupid question, can't this trivially be solved by having a movable constructor / builder type that then gets turned into a non-movable type when built?
Sure, thats one reason why IntoFuture and Future exist. Imo, in hindsight this is also main mistake in aysnc Rust: The whole async system should be build around IntoFuture rather than Future (async fn should return impl IntoFuture).
That way you could pass around IntoFutures without being affected by auto traits leaking. Only when you actually call .await() or .poll() would the immovable Future materialize.
I guess `!Move` is largely equivalent to `Unpin` for the purposes of `Pin`, so for example Pin's safe constructor `Pin::new()` can be re-expressed in terms of `!Move` instead of `Unpin`. Today you need unsafe code to pin a `!Unpin` (i.e. "movable") type.
But I also suspect there are important differences between `!Move` and `Unpin` that I'm not sure about.
This whole thread summarizes what's wrong with Pin: it's so confusing everyone in here got something wrong. (Just to address your mistake in particular Unpin is almost the opposite of !Move: it's the trait that represents things that can be un-pinned, that is: moved despite having been pinned. See https://doc.rust-lang.org/std/pin/index.html#unpin).
Give it some time and see how people will use it and problems emerging. I do feel that this will stay.
There's a different proposal by @withoutboats to make immovability a property of the place/reference instead of the type:
https://without.boats/blog/pinned-places/
Does this project goal mean that the rust maintainers have decided to implement @yoshuawuyts' immovable types proposal in favor of pinned places?
Ah, thanks, I didn't realize "pin ergonomics" was the Rust Project name for @withoutboats' pinned places.
This sounds like a similar approach to OxCaml
Although not part of the goal, it also mentions `!Destruct`/"must-move types", aka linear types: Instead of there always being a way to drop values without providing any arguments, if you wanna get rid of a value of a linear type you have to call a function that takes it by value.
For context, the reason this would be really nice is that it would enable API designs that catch certain kinds of errors.
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.
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.
> 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
Can you elaborate how it may work? I mean if I create a function:
fn fail_silently(txn: Transaction) {}
then the calling code would pass the compiler, but this function presumably isn't, ok. But what can make these functions to pass:
impl Transaction { pub fn commit(self) { ... } pub fn rollback(self) { ... } }
Would you need to destructure self or what?
Yes, destructuring is typically the only allowed way to get rid of linear/indestructible values. If the type has private fields, this is only possible in the same module, so commit(txn) and rollback(txn) would have to be implemented in the same module as the Transaction type.
Exactly - fail_silently is illegal and you have to actually destructure the type to explicitly implement the destructor
> How would you handle destructors with arguments?
https://smallcultfollowing.com/babysteps/blog/2025/10/21/mov...
Linear types requires significant work to incorporate into the core built-in collections and types. I've been following the work on Mojo to enable Linear type support for built-in types and collections, I don't think Rust's language semantics will allow for the same level of integration (Rust is already stable).
But Rust has editions.
That is a big lever language designers can use if they painted themselves into a corner.
Yes, editions are a great mechanism. It still has its limits, especially if you want easy edition migrations. All existing Rust code assumes it can drop any type whenever it wants, and that is not something you can just change across editions. You have to be very careful with defaults if you don't want conflicts when crossing edition boundaries.
The naïve idea would be to just say that all generic parameters have an implicit `where T: Move` bound, and you have to explicitly opt out of it with `where T: ?Move`, just like with `?Sized`.
In fact, that's exactly how I would expect it to work, but there may be non-obvious drawbacks.
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.
The people working on this are aware that it poses backcompat problems that don't have obvious solutions. They are looking into non-obvious solutions. https://lcnr.de/blog/2025/11/28/implicit-auto-traits-assoc-t... is the most up-to-date one I'm currently aware of.
I'm very probably missing something, but as a user I would definitely expect `Iterator::Item: Move`, but then also that `&{mut} T: Move where T: ?Move`.
But yeah I can see how these bounds are somewhat viral. Thanks!
Here is an example of the problem: https://play.rust-lang.org/?version=stable&mode=debug&editio...
Imagine if MyTrait comes from core/std. Adding an opt-out bound like ?Sized (or ?Move) is a breaking change for any generic code that relies on Sized/Move. But you want some traits from std to be open for !Move types.
Which stdlib collections and types should become `!Move`?
None. The question is more what happens when you put a `!Move` type into, say, `Vec<T>`, 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<T>` 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.
We already have a Vec<T> whose size can't change, it is called Box<[T]>. So Vec doesn't need to support !Move types.
More algebraic effects being retrofitted onto Rust.
How so? This feel distinct from the "algebraic effects"-like features like constness, async, can-panic, can-unwind, etc., since this is a property of the types themselves rather than of functions.
The traits are essentially effect handlers for effects like `drop<T>`, `move<T>`, `forget<T>` which are implicitly charged to the a function which owns a `T` and does drops, moves, or forgets it.
Inferring the capabilities of the function from the traits of the types of the arguments is similar to tracking effects. The function charges `drop<T>` when `x: T` goes out of scope, which is handled by the trait implementation. If Rust had a proper algebraic effects type system, you would be able to see this directly in the signature of the function (and even more, if the trait impls themselves had their effects tracked, you'd be able to see from the signature of the function the side effects of deallocation of its owned variables, like if `drop<File>` performs `io`).
I haven't seen any algebraic effects system that is that powerful
The closest is linear types but even then drop isn't an effect but also a function you can call to allow not continuing the references
Yeah I should have phrased that better. The traits themselves are not the effects, they're bits of code which can have side effects. Rust doesn't track those side effects in the type system yet, but !Forget especially is the essence of that idea. If you implement it for everything owned by a function, you can basically infer that the function does not have the leak effect (which would be an effect in the effect row of a Forget trait implementstjon).
If you try treat memory as an effect you gain the need for several polymorphic effect type functions drop, forget, etc which map a type to the effect row charged by its corresponding Drop, Forget impl. Rust doesn't have that type system obviously.
idk maybe that's not a bad thing?
Guaranteed destructors is probably the most complex features ever added to C++, more than templates or move semantics.
The combination of exceptions and non-trivial {copy constructor, assignment operator, destructor} are what combine to make C++ a somewhat broken language when you try to use all the features. And also responsible for poisoning the well for exceptions as an error handling mechanism for native code.
Delphi did native exceptions much better IMO.
How do native exceptions work in Delphi?
Very similar to Windows Structured Exception Handling, which the Win32 implementation used, and also looks similar to Java, but without checked exceptions. try/except/end and try/finally/end blocks.
The major differences with C++:
It's not a memory safe language, but it does give you a bunch of idioms that, if you stick to them, you don't feel nearly as much pain as C++.Does anyone know if there is any plan for no-panic to be a language feature? I think there was some discussion about this regarding Rust in the Linux kernel or embedded Rust but I don't know if there is any consensus or any plan regarding this.
This is not currently a project goal. As with many things in the Rust project, it could be, if someone wanted to step up and dedicate the required engineering resources.
But also come with a plausible implementation strategy, that from what I know is not currently known for no-panic.
mem::forget isn’t the only way you can safely leak a value, you can do it with reference cycles too, right? And there is no way for the compiler to detect that?
Isn’t that why mem::forget is safe, because you can always implement it yourself safely? How do you get around that?
> mem::forget isn’t the only way you can safely leak a value, you can do it with reference cycles too, right? And there is no way for the compiler to detect that?
But there's an easy solution for that: you make the reference-counted smart pointers require their pointee type to be Forget. It will be like how Arc<T> doesn't implement Send unless <T: Sync>.
An alternative way to "forget" a value is to hand it off to another thread that then loops infinitely.
Could of course be plugged by saying `!Forget : !Send`, but wouldn't that preclude legitimate useful scenarios for `!Forget`?
The more accurate definition of `!Forget`, similar to `Pin<&mut !Unpin>`, is not "can be leaked" but "if the underlying storage is reused, the destructor is guaranteed to run". This enables all important (decidable - preventing leaking is undecidable, even in GC languages) use-cases, and sending the value to a thread does not break this contract.
Passing ownership to another thread is not the same as forgetting/leaking.
The point of !Forget is ensuring that once the owner goes out of scope the destructor must be guaranteed to run. An infinite loop is not a problem, cause the new thread will never leave its scope. Ref-cycles are a problem, cause you can create a ref-cycle. Then the program flow leaves the scope which will run the drop on all RC's but not the drop on the inner type.
> An alternative way to "forget" a value is to hand it off to another thread that then loops infinitely.
Might be able to address that by only allowing such a handoff to a thread spawned via some scoped abstraction to ensure that progress can only be made if/when the spawned thread terminates?
By doing the same as with `Sized`: Automatically including the `Forget` bound on generic parameters and letting methods that don't need to be able to forget them opt out. That way existing code continues to compile and existing unsafe code doesn't become unsound.
This was my first question too, I don't see anything addressing e.g. the cyclical arc example from the original 'spawn' conversation.
It seems like you have to auto-propagate !Forget, and then make 'anything that be used to logically implement forget', probably most importantly things like Rc take a Forget bound and do it at an edition boundary? But the link mentions none of that...
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...
I agree with most of that, but there's one important detail (that I'm sure the designers of this proposal are thinking about): The current contract of Pin in Rust (the only standard support for expressing immobility) doesn't just cover the object's own location, but also any references derived from the object, commonly called "pin projection".
For example, if you have a `Pin<Box<Vec<u8>>>`, it's safe to turn that into a `Pin<&mut [u8]>`.
Any system that replaces `Pin` will probably have to maintain that same property, which wouldn't naïvely happen using C++-like move semantics, right? Or maybe I'm overassuming?
Hmm, I'm not sure if you're concerned about the "norad"-style run-time checked references I'm imagining or raw references. In either case, the property we (and `Pin<>`) are concerned about is whether an object can be (destructively) moved. You're pointing out a reference derived from a pinning reference essentially inheriting the pinning property. (I.e. the property that the target won't be inappropriately (destructively) moved.)
But with this proposal, the property that the object won't be (destructively) moved is (solely) a property of the object's type. Specifically, it doesn't depend on any property of any reference to the object, and certainly not on any other reference that that reference was derived from, right?
> Any system that replaces `Pin` will probably have to maintain that same property
Maybe any system that compatibly replaces `Pin`. Maybe. But I'm not sure that this proposal is overly concerned with compatibility with `Pin`. That github page explicitly mentions the desire to deprecate `Pin`, right? And like I suggested, if successful enough, it's conceivable that it could end up de facto deprecating Rust's necessarily-trivial-destructive moves in general. Conceivably.
My sense of sentiment in the project right now is that people want to keep the invariant that assignment (to an ordinary memory location) is always just a memcpy and never calls arbitrary user-defined code, because if that code does something unexpected, debugging (at least if a human's doing it) is likely to be hampered by the syntactic invisibility of the call site. This is why the most obvious ergonomic-reference-counting proposal (have a trait that lets types opt into implicit clones) ran aground, and they're now experimenting with (conceptually clunkier, in my opinion) alternatives that aim to make reference counting ergonomic but still syntactically visible.
So if Rust ever gains move constructors, you'll probably have to call them explicitly, the way you have to explicitly call .clone(). (There's actually already a third-party library that does something like this (https://docs.rs/moveit), and I think Crubit is using a similar API to let Rust code call C++ move constructors.)
One of the main reasons Rust needs this capability is because C++ has it, and Rust wants to interop with it. It's not that better model (enabling it additionally can bring benefits, but also complications; enabling it by default, like C++ does, is a terrible idea).
Give me all the liberating constraints. Get rid of panic next.
Wouldn't this be fairly substantially backwards incompatible?
By default yes. Part of the work is figuring out how to get around that.
Thank you.
Could someone explain this to me as someone who's never touched async Rust? What kind of useful patterns would this allow for?
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.)
Things you'd expect to work already.
It doesn't really add anything new and flashy, but removes some annoying warts.
Sync code has scoped threads that enable multi-threaded execution within a function, without having to ensure the data outlives the function call. Async can't do that while guaranteeing safety. This makes tokio::spawn awkward and annoying, and is a major source why people dislike Rust's async.
Low-level async code that polls Futures requires using the Pin wrapper type, which is unergonomic, and doesn't really guarantee safety, but it's more like a "be careful here" sign. Proposed changes would make that code look more like normal Rust and work without unsafe escape hatches.
> and is a major source why people dislike Rust's async
It's worth mentioning that there is, in fact, no language out there other than Rust that can even do this in the first place.
Some languages give the illusion that they support it by boxing the stack frame of async functions and letting a garbage collector deal with the consequences, but that comes with significant drawbacks too (additional GC pressure, heap allocation overhead, requiring a GC in the first place).
You can do it with C++ coroutines, but it's much harder to do correctly than in Rust if you want to maintain any sense of conviction that the system is correct.
The main reason that structured async concurrency would be so awesome to have is that it feels like Rust has the right set of features that could enable it with a set of constraints that are so much more attractive than any other language out there can provide - no overhead, "just works" with no drawbacks.
(For the record, you can actually get pretty far today using primitives like `FuturesUnordered` instead of `tokio::spawn` and similar, but this sidesteps the runtime's scheduler, so YMMV. This basically creates a task-local mini-scheduler for your futures, which may or may not be sufficient.)
C++26 adopted senders/receivers (std::execution) as its official concurrency model, with the explicit aim of supporting structured concurrency. See https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p23...
It makes it easier to write recursive async functions. It makes it easier for async functions to borrow rather than clone from their outer scope.
All really awesome, non controversial and ergonomic things.
Wait, how does it actually change the recursive async story?
The problem today is that the compiler-synthesized struct implementing `Future` for each async function cannot contain an instance of itself without boxing, because it would create a type of infinite size. That's a separate problem that's also hard to solve nicely, because the call tree might be deep, and deciding where to cut (using Box::pin) is non-trivial.
I felt this one
Little by little, Rust, like D, acknowledges that C++ flexibility regarding object construction, copy and move, even if too much as a default, is sometimes needed :)
I saw in D years ago how they also checked into this flexibility after getting some use cases for it (in this case, copying): https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1...
For what it's worth Ada currently has RFCs for constructors in destructors closer to the C++ way. They're currently supported in the GNAT (GCC Ada) compiler.
https://github.com/AdaCore/ada-spark-rfcs/blob/master/featur...
https://github.com/AdaCore/ada-spark-rfcs/blob/master/featur...
https://gcc.gnu.org/gcc-16/changes.html#ada
This is the opposite, it is further opting out of flexibility.
I guess the point is that the concepts are needed, which is true. But the Rust way (more explicit and targeted) of dealing with these concepts seems better than how either C++ or D handle it.
D is my favorite language that I wish I could use more, but the chances of me being paid to use it are too low, I wish that job market would expand, I feel like D needs a really good alternative to Vibe.d a web framework with a well designed ORM, or a rich GUI stack out of the box. Go became massive because a production ready but simple HTTP server came out of the box, and other nice to haves that made being productive in Go a breeze from day 1.
I also like d a lot even if I did not use it that much (toolchain and getting things done problems mostly, besides not great platform support).
The metaprogramming of D is really impressive.
In fact I considered using Vibe.d for some backend: it has fibers. I love stackful coros in general (virtual threads in Java, for example). Way more than stackless for most uses.
But I am afraid that Vibe.d could not be flexible enough. With Java, Python, etc. I have more than enough for my needs right now.
To be clear, this is absolutely not adding any sort of C++-style overrideable implicit move or copy constructor to Rust. There's not really any relationship to C++ in this proposal, it's just a step towards opt-in linear types.
It's relevant for C++ interop at least, but that's about it.