I think a version of Rust in which catching panics is unsafe would be entirely justifiable and probably should have been more strongly considered.
Re:The Core of Rust
by ameliaquining on Thursday August 21, 2025 @11:38PM
(#44980794)
This is one of many things that could have been done to solve the unwinding-through-linear-types problem, if it were still possible to make backwards-incompatible changes to the language.
Yes, but unlike most of the proposed solutions to this problem, this one was (1) seriously considered prior to the release of Rust 1.0, and (2) wouldn't have caused major changes to the way most people write Rust programs in practice. i.e. Rust without panic catching in safe code is still essentially Rust.
I think an interesting component is that you might also want “semi linear types”: types which are purportedly linear but can be dropped as an unwinding backstop.
For instance if you’re dealing with database transactions you probably want to make it explicit whether you commit or rollback, but on panic you can likely allow the transaction to be cleaned up automatically.
Re:The Core of Rust
by ameliaquining on Friday August 22, 2025 @09:07PM
(#44991959)
Most Rust ORMs and query builders expose a transaction API that takes a closure and runs it inside the transaction, rolling back on unwind or (in most cases) if it's not explicitly committed. This is the most common idiom in Rust for dealing with situations where you want to pass extra data to or from a cleanup routine. Unfortunately, for the async use case in particular it happens to be unsound: https://tmandry.gitlab.io/blog/posts/2023-03-01-scoped-tasks...
It was pretty much off-the-table well before that, because a usable implementation of linear types requires being able to ensure the absence of panics. (A panic must unwind the stack, which amounts to automatically running drop implementations.) The two issues are quite closely linked, and hard to address in isolation.