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 3 hours ago | parent [-]

> 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 2 hours ago \| parent \| next [-]
		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.
	▲	vlovich123 2 hours ago \| parent \| prev [-]
		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...