{"id":45180,"date":"2024-10-01T14:36:12","date_gmt":"2024-10-01T18:36:12","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=45180"},"modified":"2024-11-11T11:30:40","modified_gmt":"2024-11-11T16:30:40","slug":"swift-concurrency-and-objective-c","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2024\/10\/01\/swift-concurrency-and-objective-c\/","title":{"rendered":"Swift Concurrency and Objective-C"},"content":{"rendered":"

Paul Haddad<\/a>:<\/p>\n

\n

Anyone know why calling the following in a MainActor<\/code> class\/func<\/p>\n

MyTest.increment(1) { result in\n    NSLog(\"result=\\(result)\")\n}<\/pre>\n
crashes (asserts) when building with Swift 6?<\/p>\n
I get that its not happy that the completion is coming in on another dispatch_queue<\/code> but it should complain about it at compile time, or ignore it at run time.<\/p>\n<\/blockquote>\n
Unfortunately, it seems to be designed this way.<\/p>\n
OneSadCookie<\/a>:<\/p>\n
\n
SE-0423<\/a> “Dynamic actor isolation enforcement from non-strict-concurrency contexts” adds the crash (otherwise your “safe” Swift 6 code is unsafe).<\/p>\n<\/blockquote>\n
It’s not that the code is unsafe<\/em> but that neither the Swift compiler nor the Swift runtime can prove that it’s safe<\/em> because the MyTest<\/code> class is written in Objective-C. You are supposed to annotate your Objective-C code<\/a> so that Swift Concurrency can understand it, though this is not really documented<\/a>.<\/p>\n\n
Doug Gregor<\/a>:<\/p>\n
\n
In Swift 5 mode, this code silently introduces a data race into the program.<\/p>\n
In Swift 6 mode, the data race is caught by the dynamic isolation check. That’s the first point at which the data race can be detected, and the check is there to prevent this race from becoming weird runtime behavior.<\/p>\n
This is all as designed. If that Objective-C code were Swift 6 code, we’d catch the error at compile time. As Objective-C, runtime is the earliest it’s possible to detect the race. Enabling Swift 6 language mode means turning previously-unobserved or undiagnosed data races into ones that fail predictably to flush out any contract violations outside of the Swift 6 code. As more code enables Swift 6, the runtime checks get replaced with compile-time.<\/p>\n<\/blockquote>\n\n
Swift 6 mode is being “helpful” by proactively crashing the app even though there’s not necessarily a problem. It may be that it just doesn’t understand that GCD is being used<\/a> to call everything on the right thread.<\/p>\n\n
I get why Swift 6 is designed this way, but I don’t understand how you’re supposed to make the transition. Swift 5 mode gives no errors at compile time and doesn’t even log any errors at runtime. Swift 6 mode gives no errors at compile time and crashes at runtime. To get from one to the other you’re supposed to go through the code line-by-line and not make any mistakes.<\/p>\n\n
Personally, I’m skeptical of the benefit of switching to Swift 6 mode with a hybrid codebase. If you started off with good code, it seems more likely that you’ll get some annotation wrong and have Swift 6 trigger an unnecessary crash than that you actually discover a latent concurrency bug that matters. I think it makes more sense to migrate the code to Swift before flipping the switch. Then you can get errors at compile time instead of at runtime.<\/p>\n\n
Mike Apurin<\/a>:<\/p>\n
I think that Swift 5 mode doing nothing is part of the problem here.\nI’ve run in similar issues in Combine<\/a> and was very blindsided by it. There is no way to progressively discover and deal with such isolation violations, just enabling 6 mode and praying.<\/p><\/blockquote>\n\n
But this illustrates that porting your<\/em> code to Swift doesn’t fully solve the problem, either. It seems that you still have to annotate your closures<\/a> because of Apple’s code.<\/p>\n\n
Matt Massicotte<\/a>:<\/p>\n
\n
The core problem, in my opinion, was Combine was not updated and that’s bananas.<\/p>\n<\/blockquote>\n\n
Previously:<\/p>\n