Ok, that makes sense to me.
But then I don't understand this statement from the non-copyable types section of the announcement thread about swift-atomics 1.1 though:
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.)
Assuming that Atomic<Value> is a non-copyable type, I don't see what the syntax would be for being able to reference instances of that type in mutliple threads. Assume it's a simple counter, how can I invoke the increment operation on that counter from two different threads without sharing the non-copyable Atomic<Value> in a non-borrowable way.
Interestingly under Xcode 15 RC1, the following playground compiles (unexpectedly to me, bc I would have thought that myNonCopyable would inherently not be accessible there):
struct MyNonCopyable: Sendable, ~Copyable {
func someConcurrentOperation() -> Void { }
}
let myNonCopyable = MyNonCopyable()
let t1 = Task {
myNonCopyable.someConcurrentOperation()
}
let t2 = Task {
myNonCopyable.someConcurrentOperation()
}
But fails with the following log in the Playground log window:
error: couldn't IRGen expression. Please enable the expression log by running "log enable lldb expr", then run the failing expression again, and file a bug report with the log output.