{"id":42309,"date":"2024-03-01T14:19:05","date_gmt":"2024-03-01T19:19:05","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=42309"},"modified":"2024-03-01T14:19:05","modified_gmt":"2024-03-01T19:19:05","slug":"how-the-swift-compiler-knows-that-dispatchqueue-main-implies-mainactor","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2024\/03\/01\/how-the-swift-compiler-knows-that-dispatchqueue-main-implies-mainactor\/","title":{"rendered":"How the Swift Compiler Knows That DispatchQueue.main Implies @MainActor"},"content":{"rendered":"

Ole Begemann<\/a> (Mastodon<\/a>):<\/p>\n

\n

A bit of experimentation reveals that it is in fact a relatively coarse source-code-based check that singles out invocations on DispatchQueue.main<\/code>, in exactly that spelling<\/em>.<\/p>\n

[…]<\/p>\n

Fun fact: since this is a purely syntax-based check, if you define your own type named DispatchQueue<\/code>, give it a static main<\/code> property and a function named async<\/code> that takes a closure, the compiler will apply the same “fix” to it. This is NOT recommended[…]<\/p>\n

[…]<\/p>\n

The biggest benefit of Swift’s concurrency model over what we had before is that so many things are statically known at compile time. It’s a shame that the compiler knows<\/em> on which executor a particular line of code will run, but none of the tools seem to be able to show me this. Instead, I’m forced to hunt for @MainActor<\/code> annotations and hidden attributes in superclasses, protocols, etc. This feels especially problematic during the Swift 5-to-6 transition phase we’re currently in where it’s so easy to misuse concurrency and not<\/em> get a compiler error (and sometimes not even a warning if you forget to enable strict concurrency checking).<\/p>\n<\/blockquote>\n\n

Doug Gregor<\/a>:<\/p>\n

\n

The @MainActor<\/code> attribute is the general thing, and if DispatchQueue.main<\/code> returned a MainDispatchQueue<\/code> type whose async method took a @MainActor<\/code> closure, we’d be all set. The problem with this specific case is that DispatchQueue.main<\/code> already has a type (DispatchQueue<\/code>), and you can’t change that type without affecting source compatibility. So you would need some generalization that tries to carry MainActor<\/code>-ness along with the value. I suspect that such a generalization would generalize to, basically, just this API, so I didn’t pursue it. Given the choice between breaking source compatibility for DispatchQueue.main<\/code> (which is everywhere), inventing a bespoke feature for these cases alone, or allow-listing this pattern to help more code “just work”… I think this was rhetorical right call. Maybe we should have also deprecated this pattern over to move to an API that does take a @MainActor<\/code> closure, so the allow-list would become irrelevant over time.<\/p>\n<\/blockquote>\n\n

Holly Borla<\/a>:<\/p>\n

\n

You might be interested in this pitch<\/a> which replaces @_inheritActorContext<\/code> with a proper, non-underscored @inheritsIsolation<\/code> attribute, including replacement in Task.init<\/code>.<\/p>\n<\/blockquote>\n\n

Der Teilweise<\/a>:<\/p>\n

\n

Everything about warnings is completely broken in Xcode.<\/p>\n

When I turn on the concurrency warnings in 15.3ß3, I get ~40 warnings that disappear half a second after I click them (and come back when I switch away from the file).<\/p>\n<\/blockquote>\n\n

Previously:<\/p>\n