Swift Atomics 1.0 shipped 19 months ago -- it's long overdue for a new minor release.
I'm preparing a Swift Atomics 1.1 release that will bring this package up to date with recent developments. I'm currently planning to ship the following changes:
-
The minimum required toolchain version will increase from Swift 5.1 to Swift 5.6. This lets us get rid of a large list of workarounds for long-since resolved compiler bugs, to simplify the package and prepare it for the noncopyable future.
(Note: This will not disrupt existing projects that depend on swift-atomics: the package manager will only offer the new update to clients that are actually able to build it. Clients that are stuck on older toolchains will continue to see the existing 1.0 releases; they don't need to do any manual action to avoid the new release.)
-
The Swift Runtime has been requiring double-wide atomics since Swift ~5.5, so the toolchain bump will let Swift Atomics unconditionally ship the
AtomicReference
construct on all supported platforms. This change will finally enable widespread use of atomic strong references in Swift code.Atomic strong references are a crucial tool for (easily) avoiding memory reclamation issues in concurrent data structure work. Having this unconditionally available opens the door for some fundamentally new directions where Swift was never able to venture before. (E.g., it's difficult to overstate how much a Swift-native concurrent dictionary type would benefit the systems programming use case.)
-
ManagedAtomic
will finally become conditionallySendable
when itsValue
isSendable
. This has proved to be a constant pain point for users, especially when first trying out the package, or in the simplest production use cases. (That said, I do hope that folks will not start passing around naked atomic values in any case that is more complicated than a simple atomic counter.) -
Swift Atomics 1.1 will resolve the Swift 5.7+ type checker warning when a non-final class conforms to
AtomicReference
.class Base: AtomicReference {} // warning: Non-final class 'Base' cannot safely conform to protocol // 'AtomicValue', which requires that 'Self.AtomicRepresentation.Value' // is exactly equal to 'Self'; this is an error in Swift 6
The warning complains about a real type safety issue when subclasses of such types are used as the generic argument of
ManagedAtomic
orUnsafeAtomic
. Swift Atomics 1.1, we'll change things so the declaration above will compile without warning, but the code below will produce an error:class Derived: Base {} // OK let ref1: ManagedAtomic<Base> = .init(Derived()) // OK let ref2: ManagedAtomic<Derived> = .init(Derived()) // 1.0: // no error, silent type safety violation // 1.1+: // error: 'ManagedAtomic' requires the types 'Derived' // and 'Base' be equivalent
This can technically be considered source breaking, as such code did build in Swift Atomics 1.0. However, it was always an undiagnosed type safety violation, so this was never actually valid Swift code. This, in addition to
AtomicReference
not being available on Linux, gives me some confidence that this change will not cause problems. (Please do reach out if you know it'll be a problem for you!)
I encourage interested parties to try building the package from the main
branch before the 1.1.0 tag ships, and report any problems as soon as possible, to prevent disruption. (Note: some of the changes above have not landed on main yet. I'll follow up in this thread when we have a release candidate that is ready for testing.)
On noncopyable types
Non-copiable types are quickly approaching, and they are an important step towards modeling synchronization primitives such as atomics as Swift native constructs.
Swift Atomics 1.1 does some cleanup work in preparation for that, but it will not introduce better replacements for UnsafeAtomic
/ManagedAtomic
just yet, because no shipping Swift compiler supports move-only types today.
Additionally, SE-0390 will also not be nearly enough on its own -- we will need a considerable amount of additional language work to actually support atomics, and that may or may not happen in time for 5.9. (This followup work is yet to be designed in detail. It has not yet been pitched on S-E, but I expect it will be adapting what we learned from this thread: Exposing the Memory Locations of Class Instance Variables)
I expect Swift Atomics 1.2 will introduce Atomic<Value>
soon after the language matures enough to support it, if and when that happens. (I also expect the Standard Library to start providing the same or (similar) construct at that point, eventually replacing the need for this package altogether.)