Since we are already touching on the topic of execution semantics, here are a few examples to better visualize them.
-
Execution semantics comparison between Swift 5.5, Swift 5.7(SE-0338) and Swift 6.2(nonisolated (nonsending)). Initially, in Swift 5.5, execution semantics were sticky to the caller’s executor for nonisolated asynchronous tasks until the nonisolated code reached a real suspension point. This behavior was very similar to
Task.immediate, where, upon resumption, the nonisolated code would then continue executing on the Global Concurrent Executor (GCE). Swift 5.7 changed these semantics so that nonisolated asynchronous tasks would always and immediately hop off to the GCE. Now, with the optionalnonisolated(nonsending)feature in Swift 6.2, the caller’s executor is inherited for the duration of the call for nonisolated asynchronous tasks. -
The problem with
#isolationand function parameters. Theisolatedparameter on these functions forces the function to switch to the isolated parameter’s executor, only to immediately hop off it and switch to the GCE (when the passed-in function or closure is nonisolated and asynchronous). After all, since Swift 5.7, nonisolated asynchronous tasks always execute on the GCE regardless of the caller’s executor, which makes this easy to get wrong. SE-0461 succinctly explains why this can be confusing:
nonisolatedis difficult to understand. There is a semantic difference between the isolation behavior of nonisolated synchronous and asynchronous functions; nonisolated synchronous functions always run on the caller's actor, while nonisolated async functions always switch off of the caller's actor. This means that sendable checking applies to arguments and results of nonisolated async functions, but not nonisolated synchronous functions.
- Here is a concise example of how to resolve these issues with
nonisolated(nonsending)and why the old semantics are undesirable.
@ktoso Feel free to correct me if I got something wrong.