Zeroable should be implemented for Atomic*

[eira-fransham]

The atomic types are all bytemuck-compatible, and in fact as far as I know all bytemuck traits can be implemented for Atomic* that can be implemented for the underlying integer type as the operations available on the atomic types are a strict superset (i.e. setting their value via an immutable reference). Even casting between a non-atomic int and an atomic int should be safe, although from this discussion here rust-lang/rust#76314 it may be invalid to cast an &usize (or other scalar) to an &AtomicUsize (or other atomic scalar). This sadly means that Pod cannot be implemented without adding new traits to account for types where owned types can be cast but references cannot.

[Lokathor]

If it's unsafe to cast &usize to &AtomicUsize then the AtomicUsize type doesn't fit with Pod, because Pod allows casting between &T and &U when the size and alignment match.

Similarly, the TransparentWrapper trait isn't appropriate.

It's fine to have Zeroable, I suppose.

[eira-fransham]

I think it might make sense to have new traits for immutable access, since that would allow safe casts to/from Cell/UnsafeCell/Atomic*, but even just Zeroable would be enough since that would allow the parking_lot mutexes to be zeroable and therefore it would be possible to safely create a heap-allocated array of them using calloc using the helpers in this crate.

I'll put a PR in to implement Zeroable and leave splitting the traits to later, since it's not necessary right now.

[Lokathor]

I don't think you should read atomic values non-atomically.

[eira-fransham]

Yeah, very good point. Well, at least zeroable should be implemented.