When compiling with -strict-concurrency=complete in Xcode 14 beta 4 I am getting new warnings about mutable static properties in @unchecked Sendable types and I'm unsure if it's expected or not. Here's a simple triggering example:
final class Foo: @unchecked Sendable {
static var bar = false
func baz() -> Bool {
Self.bar // Reference to static property 'bar' is not concurrency-safe because it involves shared mutable state
}
}
The only way to silence the warnings I've found is to make another class to hold that state which feels heavy:
final class BarHolder: @unchecked Sendable {
var bar = false
}
final class Foo: @unchecked Sendable {
static let barHolder = BarHolder()
func baz() -> Bool {
Self.barHolder.bar
}
}
Assuming this isn't a bug, I think I see the logic that @unchecked Sendable would only apply to instance properties. If that's the case though, is there a new way to effectively say "let me worry about keeping instance and static level stuff safe and come what may"?
The compiler is warning that the Foo.bar global is not thread-safe. Indeed, one thread could read it while another is writing into it, with funny results.
One way to avoid such compiler warnings is to use unsafe/unchecked patterns, in order to tell the compiler: "this is not thread-safe but I promise I know what I'm doing and I don't write bugs".
But if you're not quite confident about what you are doing, or if writing unsafe code makes you uncomfortable, then you could:
Attach your globals to a global actor. For example: @MainActor static var bar = false
Wrap your global in a Sendable wrapper that uses a lock in order to fulfill the Sendable requirements.
Probably other forum members will have more information and advice to share. I dearly wish I could read a "Best practices for properly dealing with globals in Swift" guide somewhere, because this topic is hard, many code bases contain globals, not many Swift developers are familiar with the new concurrency features, and I wouldn't like Internet to be full of techniques that silence warnings but leave the code in an unsafe state.