I don't expect the use of .relaxed itself would by itself break anything here -- relaxed loads/stores of atomic references still end up calling the usual Swift retain/release entry points, so you are still guaranteed to get the same fences as you normally get when loading/storing a Swift reference. (Which isn't a very strong guarantee, but it at least gives you the usual semantics.)
By the way, I'd be very much interested in hearing about practical experience using AtomicReference -- I think it's a reasonably simple memory reclamation solution, but I don't really know how well it works in real life situations. For the simplest cases, it may or may not compare favorably against a regular (fast) lock -- it may be worth running a few benchmarks and see. (For more complex situations, its performance is unlikely to compare well against custom-tailored memory reclamation strategies, but it seems hard to beat its semantics -- it sort of emulates the ease of memory reclamation in a garbage collected platform, so using it can be a nice way to port algorithms that were targeting one of those.) Do let me know if it proves useful (or not!).
to me, the usefulness of AtomicReference was never in doubt: of course it’s useful! the alternative is submitting a read operation to an actor, and waiting for that future to complete. so the fact that it is the only straightforward way to publish data that is larger than 8 bytes long without having to figure out how to implement a lock (something i thought was a bad idea, according to the other thread) or implement a custom memory allocator is enough to make it useful.
of course there is one reason why AtomicReference is not useful: it’s really hard to compile code that uses it, because of all the unsafe flags that need to be passed to make it available in the first place. i got pretty far by passing them manually from the command line, but this is not really well-supported by SPM, and they don’t seem to work with cSettings/swiftSettings in the package manifest. and packages that use unsafe flags cannot themselves be dependencies of other packages.
so it would be really helpful to me if this was enabled by default and i could depend on swift-atomics with AtomicReference as a normal package.