{"id":45034,"date":"2024-09-20T15:38:46","date_gmt":"2024-09-20T19:38:46","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=45034"},"modified":"2024-11-14T14:49:19","modified_gmt":"2024-11-14T19:49:19","slug":"unwanted-swift-concurrency-checking","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2024\/09\/20\/unwanted-swift-concurrency-checking\/","title":{"rendered":"Unwanted Swift Concurrency Checking"},"content":{"rendered":"

I’m not adopting Swift Concurrency yet—it’s not even available<\/a> on the OS versions I’m targeting—so my plan was to take advantage of the Swift 5 language mode<\/a> of the Swift 6 compiler:<\/p>\n

\n

The Swift 6 language mode is opt-in<\/em>. Existing projects will not switch to this mode without configuration changes.<\/p>\n<\/blockquote>\n

I had SWIFT_VERSION<\/code> set to 5<\/code>, and this worked great when compiling my apps with beta versions of macOS 15 and Xcode 16 over the summer. I needed to make some minor updates<\/a> to my code to compile with Swift 6 but none were related to concurrency.<\/p>\n

However, after updating to the release version of Xcode 16 (since macOS 15 won’t run Xcode 15.4), I started getting this error:<\/p>\n

Capture of 'buffer' with non-sendable type 'UnsafeMutableBufferPointer<T>' in a `@Sendable` closure; this is an error in the Swift 6 language mode\n\nGeneric struct 'UnsafeMutableBufferPointer' does not conform to the 'Sendable' protocol (Swift.UnsafeMutableBufferPointer)\n<\/blockquote>\n

from this code:<\/p>\n

DispatchQueue.concurrentPerform(iterations: count) { (index) in\n    buffer[index] = \/\/ …\n}<\/pre>\n
The GCD API is marked with @preconcurrency<\/code>:<\/p>\n
@preconcurrency public class func concurrentPerform(iterations: Int, execute work: @Sendable (Int) -> Void)<\/pre>\n
but that didn’t stop it from complaining.<\/p>\n
I don’t know whether this is a bug, but it’s certainly not what I expected after repeatedly hearing<\/a> that strict concurrency checking is opt-in. Reading the details<\/a>:<\/p>\n
\n
You can address data-race safety issues in your projects module-by-module, and you can enable the compiler’s actor isolation and Sendable<\/code> checking as warnings in the Swift 5 language mode, allowing you to assess your progress toward eliminating data races before turning on the Swift 6 language mode.<\/p>\n<\/blockquote>\n
It seems that you can “enable” the checking as warnings by setting SWIFT_TREAT_WARNINGS_AS_ERRORS<\/code> to NO<\/code>, but I don’t want to do that because I do want other types of warnings to be treated as errors. There’s not yet<\/a> a way to control warnings individually. And, also, I don’t want to see concurrency warnings with every build when I’m not going to be actively fixing them for a while. There is a separate SWIFT_STRICT_CONCURRENCY<\/code> build setting, but there doesn’t seem to be a way to turn it off, only to minimal<\/code>, which still reports this warning\/error.<\/p>\n
I’m not the only one to run into this exact issue. Frank Rupprecht<\/a> found that the warning can be avoided by assigning the closure to a variable, rather than passing it directly:<\/p>\n
let closure = { (index: Int) in\n    buffer[index] = \/\/ …\n}\nDispatchQueue.concurrentPerform(iterations: count, execute: closure)<\/pre>\n
It’s not clear to me whether this is a hack exploiting a compiler bug<\/a> or a designated opt-out akin to how GCC treats putting an assignment expression in parentheses<\/a>. But I’m going with this for now because it seems silly to rewrite the code<\/a> for Swift Concurrency when (a) I’m not using that yet, and (b) GCD is a separate world, anyway.<\/p>\n\n
Jesse Squires<\/a> discusses a related issue when he does<\/em> have strict concurrency checking enabled:<\/p>\n
I was confronted with this warning in a project recently and I want to share the hack for how I worked around it. The issue was the result of a combination of factors I mentioned above. I was interacting with @preconcurrency<\/code> APIs and<\/strong> I knew my code was concurrency-safe, but I was unable to accurately express that to the compiler.<\/p>
[…]<\/p>
So, we have situation where the Swift compiler is telling us that the closure being captured needs to be @Sendable<\/code> but we cannot make it @Sendable<\/code>. It is also telling us that the closure loses its @MainActor<\/code> but we know that the closure will always be called from the main queue. Because of these two problems, we need to find a way to work around the warnings and coerce the compiler into doing what we want.<\/p><\/blockquote>\n\n
I also got a similar error about capturing a non-sendable type when using these methods:<\/p>\n
@MainActor func filePromiseProvider(_ filePromiseProvider: NSFilePromiseProvider, fileNameForType fileType: String) -> String\n\nnonisolated func filePromiseProvider(_ filePromiseProvider: NSFilePromiseProvider, writePromiseTo url: URL) async throws<\/pre>\n
I was already using the queue supplied by the provider, but Swift Concurrency doesn’t know that. Here I was able to silence the error by using:<\/p>\n
nonisolated(unsafe) let provider = \/\/ …<\/pre>\n\n
Finally, I got this error:<\/p>\n\n
Struct 'Notification' does not conform to the 'Sendable' protocol (Foundation.Notification)<\/blockquote>\n\n
with this code:<\/p>\n
queue.async(flags: .barrier) {\n    DispatchQueue.main.sync {\n        f(notification)\n    }\n}<\/pre>\n
I’m ensuring that the notification is only used on the main thread, but Swift Concurrency doesn’t realize that. Again, I was able to silence the error using nonisolated(unsafe)<\/code>. It’s not clear to me whether assumeIsolated()<\/code> might be more appropriate in this situation, but I can’t use it, anyway, because that API doesn’t back deploy far enough.<\/p>\n\n
Previously:<\/p>\n