Rust project goals: Immobile types and guaranteed destructors

Join the discussion

• Hacker News
• > Haskell is a very good language for writing this kind of application.

  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.

  by drnick1
• Where was Haskell mentioned?
  by three_burgers
• Intresting. Immovability becomes a property of the type (!Move) rather than the place (Pin), and the goal is to eventually deprecate Pin outright rather than paper over it with pin ergonomics. !Forge is what finally unblocks safe scoped spawn: handle that can't be mem::forgeten has a destructor that's guaranteed to run.
  by _alphageek
• Could someone explain this to me as someone who's never touched async Rust? What kind of useful patterns would this allow for?
  by suddenlybananas
• 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.

  by aabhay
• 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.

  by pornel
• 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.)

  by simonask
• 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...

  by safercplusplus
• 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).
  by afdbcreid
• 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?

  by simonask
• Guaranteed destructors is probably the most complex features ever added to C++, more than templates or move semantics.
  by groundzeros2015
• 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.

  by barrkel
• 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?

  by OskarS
• 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...

  by Falell
• 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.
  by skitter
• > 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>.

  by stymaar
• More algebraic effects being retrofitted onto Rust.
  by Tazerenix
• idk maybe that's not a bad thing?
  by sysguest
• And as a language feature, not as a library.
  by thesz
• 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.
  by dubi_steinkek
• 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.
  by dorjoycb
• 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.
  by ameliaquining
• 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.
  by skitter
• 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).
  by melodyogonna
• 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.

  by simonask
• 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?

  by yccs27
• This sounds like a similar approach to OxCaml
  by rienbdj

•     > # 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.
  

  https://github.com/rust-lang/rust-project-goals/blob/main/sr...
  by Ygg2
• 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.

  by stymaar
• > 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...

  by q3k