← Back to context

Comment by skitter

14 hours 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.

15 comments

skitter

Reply
simonask  13 hours 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  11 hours 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?

    • yccs27  10 hours 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.

melodyogonna  13 hours 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  12 hours ago

    But Rust has editions.

    That is a big lever language designers can use if they painted themselves into a corner.

    • yccs27  10 hours 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.

      5 replies →

  • dubi_steinkek  10 hours ago

    Which stdlib collections and types should become `!Move`?

    • simonask  9 hours ago

      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.

      1 reply →