Rust project goals: Immobile types and guaranteed destructors
github.com
github.com
It (the immobile types proposal) 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.
I'm very glad they found a way to add it eventually, as it's really filling a glaring hole in the language.
Will this integrate with existing code that uses Pin<T>? If not this will split the ecosystem even further...
But I also suspect there are important differences between `!Move` and `Unpin` that I'm not sure about.
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.
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.
Since it's just a matter of how async get desugared, can it be changed through an edition?
To dump some ideas on you: I think one missing piece might be that FnOnce() -> impl Future should implement IntoFuture. Async runtimes would then use IntoFuture in their APIs agressively.
I call this a "workload blueprint" at work. Its a closure/type that contains all the info to start the workload, but in a minimal form. In Rust terms this would be a buildprint that is ideally Send + Move + Forget + 'static, even if the actual work (and the backing struct of the Future) is !Send (e.g. It holds an Rc across await points).
Runtimes could use this for their advantage: There would be a global pool of "workload blueprint" that can be stolen by any executer thread, but once a !Send workload has started on one thread it can't be migrated to another.
This in combination with matklad's ideas about seperating TaskSend from ThreadSend (https://matklad.github.io/2023/12/10/nsfw.html) would solve most of my async pain points.
You could model this with a state machine enum where the "stay put" phase is a variant that accepts a !Move, like so:
enum StateMachine<PinnedState: ?Move> {
InitialState,
State1(String),
State2(Box<PinnedState>),
TerminalState,
}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?
> # 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.
let txn = create_transaction();
// do something with the transaction
txn.commit(); // consume the txn
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 });
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.
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?
> How would you handle destructors with arguments?
https://smallcultfollowing.com/babysteps/blog/2025/10/21/mov...
That is a big lever language designers can use if they painted themselves into a corner.
In fact, that's exactly how I would expect it to work, but there may be non-obvious drawbacks.
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.
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.
First of all they don't apply to the standard library currently, secondly the kind of automatic changes that are enabled and supported by rust fix, are limited.
It is not anything goes.
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.
Not to mention it's still not easy: to have any usefulness, there will need to be a way to be generic over it (similar to keyword generics), and that's far from trivial.
If this is the "trivial" implementation, then I'm not sure what a "nontrivial" implementation would look like, unless it means adding a proof-tactics language to Rust to allow statically checked proofs of arbitrary program properties. Which would be really cool and all kinds of useful, but which I think everyone realizes would be a gargantuan project even to design, let alone implement.
Genericity is not strictly required for no-panic to be useful (lots of type-system features still don't have it), but yes, it would be very nice to have. (Though one might hope that, once they figure out genericity for one keyword (probably const), that'd make it easier to add for others.)
Should indexing an array with a constant be marked? What is considered to be a constant? Those are complicated questions.
If you do not want genericity nor complicated handling, you can already get yourself covered, pretty much. Clippy has lints for panicking language operations/basic std functions, and it should be possible to write a linter that automatically infers if a function can panic.
Constants are well-defined in Rust; panicking operations like array indexing would be allowed within no-panic functions in const contexts (https://doc.rust-lang.org/reference/const_eval.html#const-co...), but not otherwise.
There's a difference between genericity over no-panicness (which I argue is not needed for an MVP) and allowing otherwise generic functions to be no-panic (which I do think is required). I don't think a linter can do the latter, because it would need to integrate with the trait system (e.g., you would need a NoPanicDrop trait and possibly NoPanicFn(|Mut|Once) traits).
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`).
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
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.
Isn’t that why mem::forget is safe, because you can always implement it yourself safely? How do you get around 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>.
Could of course be plugged by saying `!Forget : !Send`, but wouldn't that preclude legitimate useful scenarios for `!Forget`?
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?
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.
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...
Delphi did native exceptions much better IMO.
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
Agree with the rest, I always loved how Borland picked Object Pascal extensions from Apple, merged them with what was going on with Modula languages and C++ during the 1990's, while coming out with something saner.
While at the same time keeping C++ around, as market value when buying the whole package.
What everyone is going crazy regarding Zig, Odin, Jai, C3, whatever improvements over C and C++, where already available in Delphi, Modula-2, Ada and co, with Delphi being the most affordable option until Borland decided to pivot to big corp.
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...
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?
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.
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.)
All really awesome, non controversial and ergonomic things.
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.
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.
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.)
Like, the central challenge is cancellation: In structured concurrency, subtasks spawned from a parent task must finish cancelling before the parent task can be cancelled.
Could you elaborate on this?
This is a compile error in Rust, and you need unsafe code to achieve it. But then the real power is that you can construct a safe API that lets you do it safely, fully checked at compile time.
See `std::thread::scope` in the standard library, or `rayon::scope` if you want an implementation based on thread pools.
>See `std::thread::scope` in the standard library, or `rayon::scope` if you want an implementation based on thread pools.
These seem to be about multu-threaded code if I got it right, but how does async work?
I won't touch Pandoc with a ten foot pole because of the endless Haskell dependencies on Arch Linux. So no, Haskell is a pretty horrible choice.
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...
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.
https://github.com/AdaCore/ada-spark-rfcs/blob/master/featur...
https://github.com/AdaCore/ada-spark-rfcs/blob/master/featur...