OK, here are some concrete steps that I can start making on my part:
-
Ship a feature release for Swift Atomics, switching its focus from obsolete Swift compilers to modern ones, and delivering some sorely missing new functionality. This is fully in progress now: see the thread [Announcement] Planning for Swift Atomics v1.1
-
Replace C atomics with llvm intrinsics that are native to Swift, initially as an experimental package variant. Ideally wrappers of these intrinsics would then ship as underscored additions in the stdlib, enabling the package to wean itself off of its kludgy _AtomicsShims module. This would let people who are currently blocked on SPM's inconsistent support for C modules to start using the package. (Including, e.g., people who want to use it on platforms such as Swift Playgrounds, or people who struggle with weird build system problems elsewhere.)
Doing this will make it far less important to ship this package as part of the toolchain distribution, but, of course, it will not eliminate the urgent need for atomics directly shipping in the Swift Standard Library. (I don't really get the point of, e.g., shipping
@unchecked Sendablewhile we don't have any synchronization constructs beyondisKnownUniquelyReferencedin the stdlib.) -
Meanwhile, I'll keep loudly crying about the continued lack of language support for properly modeling these things. The idea of accessing blocks of memory with a stable address is a really promising one. It has been around since Nov 2019 at least.
I'm a library/frameworks engineer with way too many things on my plate already, so unfortunately it doesn't seem likely I would be able to contribute a compiler patch myself -- but I'd jump on any opportunity to try integrating things...
If anyone is currently twiddling their thumbs looking for a small/mid-scale compiler project, implementing Joe's idea would be a good way to make an enormous impact with relatively small investment!