Marking a method or variable with @MainActor doesn't guarantee that it will be called on the main thread - but that's what people are probably expecting, and this can lead to errors.
It's pretty easy to get caught out with a call to a @MainActor method on a background thread - particularly if you're using ObjectiveC or frameworks/libraries with asynchronous callbacks (like CoreBluetooth).
In your examples, you show that Obj-C method dispatch can be used to invoke a @MainActor function from another thread. I think that's likely unintentional - in other words, a bug. Have you filed a Github issue or Apple feedback report about it?
It's not a diagnostics issue; it's a memory safety issue.
As for solutions, maybe it's possible for the Obj-C versions of these functions to be secretly be some kind of wrapper which checks the thread?
Is the -Xfrontend -enable-actor-data-race-checks command-line option what you're looking for? This enables runtime warnings (or fatal errors if you set the appropriate env variable) for using an actor-confined thing from outside that actor. I assume it will become the default in Swift 6.
Oh wow, I totally missed that one. Yeah, that seems like a very straightforward bug that definitely shouldn’t compile when concurrency checking is enabled. Looks like we’re skipping actor isolation checks when we convert a key path literal to its corresponding function.
The documentation you’re looking for here probably falls out of the proposal for actors (SE-0306) and global actors (SE-0316). I’m not sure you’ll find quite such a pithy quote , but SE-0316 does say this:
Note that the data in this view controller, as well as the method that performs the update of this data, is isolated to the @MainActor . That ensures that UI updates for this view controller only occur on the main thread, and any attempts to do otherwise will result in a compiler error.
And the proposals are broadly clear that, at least within Swift, actor isolation isn’t really ‘optional’—it should be that anything isolated to an actor (global or otherwise) cannot be synchronously accessed from outside that isolation domain.
One of the tests for the actor data race warning is also something that I'd expect to be a compile error as it's very straightforwardly doing something which violates actor isolation. The other one which uses an unsafeBitCast is reasonable though.