3 ms·

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 prov

by skitter 2mo ago

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.

simonask 2mo ago
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.
- ordu 2mo ago
  > 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?
  - vlovich123 2mo ago
    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/move-destruct-leak/ https://smallcultfollowing.com/babysteps/blog/2025/10/21/mov...
  - yccs27 2mo ago
    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.
- afdbcreid 2mo ago
  The question (one question, at least) is what to do with unwinding. If we consider every function to be able to unwind, that means you basically need to have a lot of boilerplate, and it's also not clear how to express that syntactically. Even differentiating `panic = "abort"` is not simple, as there is no language feature currently that does that.
melodyogonna 2mo ago
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).
- virtualritz 2mo ago
  But Rust has editions. That is a big lever language designers can use if they painted themselves into a corner.
  - yccs27 2mo ago
    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.
    - simonask 2mo ago
      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.
      - Dagonfly 2mo ago
        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.

by skitter 2mo ago

simonask 2mo ago

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.

ordu 2mo ago
> 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?
- vlovich123 2mo ago
  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/move-destruct-leak/ https://smallcultfollowing.com/babysteps/blog/2025/10/21/mov...
- yccs27 2mo ago
  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.
afdbcreid 2mo ago
The question (one question, at least) is what to do with unwinding. If we consider every function to be able to unwind, that means you basically need to have a lot of boilerplate, and it's also not clear how to express that syntactically. Even differentiating `panic = "abort"` is not simple, as there is no language feature currently that does that.

melodyogonna 2mo ago

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).

virtualritz 2mo ago
But Rust has editions. That is a big lever language designers can use if they painted themselves into a corner.
- yccs27 2mo ago
  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.
  - simonask 2mo ago
    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.
    - Dagonfly 2mo ago
      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.