Atomic types don't implement RefUnwindSafe

[tomaka]

They probably should.

[tomaka]

Hmm, actually I'm no longer sure.

The reason why Mutex and RwLock implement RefUnwindSafe is because of their poisoning mechanism.

If we take for example struct Foo { a: AtomicUsize, b: AtomicUsize } which, as a semantic rule, must always have a and b have the same value, then that struct is not automatically unwind safe. It would be unwind-safe if it used Mutexes, as the mutex would become poisoned.

[alexcrichton]

The way I personally think about panic safety is that a rule of thumb is that if you can get past thread::spawn then you're panic safe. Put another way, if a type implements both Send and 'static then it is defacto panic safe as it can already cross a panic boundary (thread::spawn).

We would have impl<T: Send + 'static> UnwindSafe for T but coherence runs afoul there unfortunately. If specialization is stabilized then we'd consider this for specialization I believe, however.

[glaebhoerl]

This doesn't seem right to me? Per the docs:

The general idea is that any mutable state which can be shared across catch_unwind is not unwind safe by default.

Atomics fit that description.