[Announcement] Planning for Swift Atomics v1.1

Atomic values are fundamental to managing concurrency, but they are far too low level to be used lightly, or to be passed around between components as if they were harmless little integers. These things are scary. They bite. They leave scars that never heal.

The best way to deal with atomics is to avoid using them them at all.

If that doesn’t work, the next best option is to strictly encapsulate them as implementation details in a higher-level synchronization/concurrency construct that is actually suitable for use without wearing a hazmat suit. (A concurrent dictionary for caching stuff would be a great example of this — the Swift runtime is chock full of those. Reflection and Observables are two topics randomly grabbed from recent evolution headlines that could really use a Swift-native implementations for that. Other examples would be concurrent FIFO queues, or similar list-like things.)

Atomics enable brave folks with sad, but steely eyes to start writing those things directly in Swift, rather than shamefully calling down to a legacy language, such as C++.

Atomics, locks, and similar synchronization primitives will breath life into the (presently) hollow promise that is @unchecked Sendable.

The Sendable conformance is largely irrelevant in this context — because the point of these things is to allow people to do the gruesome work of manually implementing Sendable conformances on things other than plain old bags of values.

However, sometimes all we need is a simple, unsophisticated atomic counter, and for that, ManagedAtomic conforming to Sendable is going to come really useful. (As long as we keep in mind that these things will wreak havoc at the slightest provocation. A function that takes or returns an atomic value, or a closure that captures one will always have a vaguely revolting smell about it.)

24 Likes