Karoy, thank you very much for continuing to work on atomics!
Sorry, but I can't find the community discussion of the second revision -- could someone point me at the thread?
I'm afraid I can't provide a review of this proposal because I have a hard time understanding what exactly is being proposed, what changes are made to the language, what changes are made to the library, and what is just sample code that demonstrates usage of newly added capabilities.
I don't understand the role of the https://github.com/apple/swift-se-0282-experimental package. Is it intended to be a just some experimental code, or is it intended to become a part of the standard library? I get mixed signals:
On one hand, the proposal says "Effect on ABI Stability: None." Therefore, no code will be added to the standard library.
On the other hand, the location and name of this package makes it look like a Standard Library Preview package, as described by https://swift.org/blog/preview-package/. That page says
The preview package provides access to functionality that has been accepted into the Swift standard library through the Swift Evolution process, but has not yet shipped as part of an official Swift release.
I interpret that to mean that the preview package will be added to the standard library after the review concludes.
The proposal also says "While this proposal enables the use of C's atomics operations in Swift code", but I don't understand through which mechanism. In the preview package (which might not even become a part of the standard library), the entry points for wrappers of C's
stdatomic.h APIs are a part of the
_AtomicShims module. The underscore in the name implies that
_AtomicShims is an implementation detail, not a public API. If so, I don't understand how the proposal enables the use of C's atomics from Swift.
I might be completely misunderstanding the direction and the intent, but it seems to me that the proposal that enables the use of C's atomics in Swift would be changing the Clang importer to enable importing
_Atomic qualified types as some corresponding Swift overlay types, with corresponding wrappers from
_AtomicShims available from the libc overlay.
If the proposal only clarifies the interaction between Swift's and C's memory model, does not change the standard library API, does not change Clang importer behavior, does not add any new modules to the standard library, does not change the libc overlay etc., then I support the proposal. However, the https://github.com/apple/swift-se-0282-experimental package must be renamed so that it does not look like a Standard Library Preview package that contains stable APIs that were approved by the evolution process. It would be also great if the proposal text was also adjusted to clearly say that the referenced repository is just sample code and not a part of the proposal itself.
One thing that the proposal (and the provided preview package) does not address is the consume memory ordering. Could we say that we upgrade it to acquire from the point of view of Swift?