Help wanted: what to do with UnwindSafe and RefUnwindSafe

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

Start by reviewing the linked open and past Rust issues about UnwindSafe, then compare GitHub code-search results with responses from the linked Twitter and Mastodon posts. Record meaningful uses, AssertUnwindSafe workarounds, and implementation concerns in a research summary. Done means a backwards-compatible deprecation or documentation plan is written for an RFC.