なるほど？ By declaring this variable as a var, we opt into Swift's dynamic exclusivity checking for this property, so all non-exclusive accesses incur a runtime check to see if there is an active exclusive (e.g. mutating) access. This inherently means that atomic operations through such a variable will incur undesirable runtime overhead -- they are no longer purely atomic. (Even if the check never actually triggers a trap.) To prevent users from accidentally falling into this trap, Atomic (and AtomicLazyReference) will not support var bindings. It is a compile-time error to have a var that has an explicit or inferred type of Atomic. https://github.com/swiftlang/swift-evolution/blob/main/proposals/0410-atomics.md#interaction-with-existing-language-features
1