Isolated(any)

Summary

Ahh, @isolated(any). It’s an attribute of contradictions. You might see it a lot, but it’s ok to ignore it. You don’t need to use it, but I think it should be used more. It must always take an argument, but that argument cannot vary. Confusing? Definitely. But we’ll get to it all. To understand why @isolated(any) was introduced, we need to take a look at async functions. let respondToEmergency: () async -> Void This is about as simple a function type as we can get. But, things start to get a little more interesting when we look at how a function like this is used. A variable with this type must always be invoked with await. await respondToEmergency() This, of course, makes sense. All async functions must be called with await. But! Consider this: let sendAmbulance: @MainActor () -> Void = { print("🚑 WEE-OOO WEE-OOO!") } let respondToEmergency: () async -> Void = sendAmbulance await respondToEmergency() The explicit types are there to help make what’s going on clear. We first define a synchronous function that must run on the MainActor. And then we assign that to a plain old, non-MainActor async function. We’ve changed so much that you might find it surprising this even compiles. Remember what await actually does. It allows the current task to suspend. That doesn’t just let the task wait for future work to complete. It also is an opportunity to change isolation. This makes async functions very flexible! Just like a dispatcher doesn’t sit there doing nothing while waiting for the ambulance to arrive, a suspended task doesn’t block its thread. When the dispatcher puts you on hold to coordinate with the ambulance team, that’s the isolation switch - they’re transferring your request to a different department that specializes in that type of work. But change to where, exactly? Ok, so we know that async functions, because they must always be awaited, gain a lot of flexibility. We are close, but have to go just a little further to find the motivation for this attribute. func...