I believe blowing the Atomic name for this would be a mistake. I don't see an upgrade path from a resilient Swift struct to a @frozen move-only type.
This seems like an irresponsible move to me. The static pointer-based methods aren't exposed as public API because they're practically impossible to use correctly in the current language. (This is also true for UnsafeAtomic, but at least the initializer's @_nonEphemeral annotation provides a compiler warning for the most egregious forms of misuse, and UnsafeAtomic provides a clear path for plugging into a potential @RawStorage feature.)
I spent a day or so on a bit of soul searching. It seems like we're stuck with two equally bad options:
- Managed atomics via classes. These would be memory safe, but come with refcounting and heap allocations for every atomic variable, so they aren't fit for purpose.
- Unsafe atomics via
UnsafeAtomicor naked pointer APIs. These ostensibly allow inline storage, but given that Swift does not currently provide a sensible way to create such inline storage, providing these right now would be extremely irresponsible.
The proposal is as complex as it is because it is trying very very hard to shoehorn the library-level parts of @RawStorage from Exposing the Memory Locations of Class Instance Variables into the atomics feature set. This is why there is so much pushback on the UnsafeAtomic construct -- it works toward a vision that the Core Team has not yet accepted as correct.
So I think the only right option is to table this proposal for now, and return to it when we've decided how we want to provide stable memory locations for atomics and similar lightweight synchronization constructs.
The work that has gone into this so far won't go to waste -- the atomic operations themselves and the protocol hierarchy looks right to me, and I'm pretty sure we can just apply them to whatever we come up with. Removing the tedious memory management discussions will also free up precious space in the proposal to round out the atomics feature set with additional constructs, including hugely important abstractions for lock-free data structures (atomic strong references, versioned atomic values), and inessential additions like atomic floating point and boolean operations.
If we like, we can use the rest of this review period to discuss the parts of the proposal that are about actual atomics. 