Help wanted: what to do with UnwindSafe and RefUnwindSafe

[m-ou-se]

It has been suggested many times that UnwindSafe and RefUnwindSafe are more often an annoyance than they are useful, and that it might be time to effectively disable/remove them.

Doing so requires some research and the design of a backwards compatible deprecation path.

To do:

• [ ] Find out how often these traits are used in a meaningful way (and how much correctness depends on it), vs how often people just ignore these traits using AssertUnwindSafe
  • [ ] Collect info through social media: Twitter, Mastodon
  • [ ] Ask input with a blog post on the Rust Blog?
  • [ ] Look through GitHub code search or similar
• [ ] Look through all open and past issues about these traits: https://github.com/rust-lang/rust/issues?q=in%3Atitle+UnwindSafe
• [ ] See how often these traits are implemented incorrectly
  • [ ] Including in the standard library
  • [ ] How often that is deliberate vs by accident
• [ ] Write up a summary of all the research above
• [ ] Decide whether it's worth changing anything
• [ ] Make a plan for deprecating/removing them in a backwards compatible way (E.g. by implementing them for all types and marking them as #[deprecated], or by removing the UnwindSafe bound from catch_unwind, or something else.)
• [ ] Maybe implement it for a crater run, to gather more confidence the plan will work.
• [ ] Post the plan as an RFC.
• [ ] Discuss RFC and get it approved.
• [ ] Implement it.
• [ ] Ship it.

Or, if it turns out to be a bad idea to deprecate these traits:

• [ ] Find out what users find confusing about these traits.
• [ ] Improve the documentation to fix that.
• [ ] Maybe: work out a plan to rename the traits, to avoid the word 'unsafe'.

[joboet]

Actually I wanted to write a blog post about this, but I have been procrastinating that for too long...

I think the two biggest problems are that

1. being auto-traits, it's incredibly easy to accidentally introduce/delete their implementation.
2. they do not allow mutation, even when it leaves everything consistent. E.g. a &mut i32 should be UnwindSafe, because i32 does not have any invariants that may be broken.

For me, the ideal design would have used two safe non-auto marker traits, Consistent and RefConsistent (as in database consistency), where Consistent implies/requires RefConsistent. These would be implemented where operations by-value/by-ref cannot break the invariants of the type they are implemented on. So all primitives would be Consistent and RefConsistent, because they do not have invariants. BinaryHeap would implement Consistent (if T implements it), because it guarantees the heap invariants stay intact with every operation (in particular, PeekMut cannot be used to break the ordering invariant). But types that allow breaking the invariants (even temporarily) through their API should not implement them, as if a panic or a leak occurs they are left in an inconsistent state. These traits could then have been used in Mutex and RwLock instead of lock poisoning, and in catch_unwind to require that the closure only holds/references types that are Consistent/RefConsistent.

I doubt that these could be introduced in exactly that fashion, but maybe lint-traits (as in marker traits that warn instead of generating an error if unimplemented) would allow their introduction in a backwards-compatible way.

[VorpalBlade]

These traits could then have been used in Mutex and RwLock instead of lock poisoning, and in catch_unwind to require that the closure only holds/references types that are Consistent/RefConsistent.

That would severely restrict what types could be protected by a mutex. In an ideal would that might work, but there would need to be an escape hatch and get the poisoning behaviour instead. Perhaps via some sort of Mutex<Poisoning<T>>, but I suspect the mutex would need to know about this inner layer.