Exploring concurrency modifications in Swift 6.2 – Donny Wals

It is no secret that Swift concurrency may be fairly tough to study. There are loads of ideas which can be totally different from what you are used to while you had been writing code in GCD. Apple acknowledged this in certainly one of their imaginative and prescient paperwork they usually got down to make modifications to how concurrency works in Swift 6.2. They are not going to alter the basics of how issues work. What they’ll primarily change is the place code will run by default.

On this weblog put up, I would love to check out the 2 important options that may change how your Swift concurrency code works:

1. The brand new nonisolated(nonsending) default characteristic flag
2. Working code on the principle actor by default with the defaultIsolation setting

By the tip of this put up you must have a reasonably good sense of the affect that Swift 6.2 can have in your code, and the way you ought to be transferring ahead till Swift 6.2 is formally out there in a future Xcode launch.

Understanding nonisolated(nonsending)

The nonisolated(nonsending) characteristic is launched by SE-0461 and it’s a fairly large overhaul by way of how your code will work transferring ahead. On the time of scripting this, it’s gated behind an upcoming characteristic compiler flag known as NonisolatedNonsendingByDefault. To allow this flag in your challenge, see this put up on leveraging upcoming options in an SPM package deal, or in the event you’re trying to allow the characteristic in Xcode, check out enabling upcoming options in Xcode.

For this put up, I’m utilizing an SPM package deal so my Bundle.swift comprises the next:

.executableTarget(
    identify: "SwiftChanges",
    swiftSettings: [
        .enableExperimentalFeature("NonisolatedNonsendingByDefault")
    ]
)

I’m getting forward of myself although; let’s speak about what nonisolated(nonsending) is, what downside it solves, and the way it will change the way in which your code runs considerably.

Exploring the issue with nonisolated in Swift 6.1 and earlier

While you write async capabilities in Swift 6.1 and earlier, you would possibly accomplish that on a category or struct as follows:

class NetworkingClient {
  func loadUserPhotos() async throws -> [Photo] {
    // ...
  }
}

When loadUserPhotos is known as, we all know that it’ll not run on any actor. Or, in additional sensible phrases, we all know it’ll run away from the principle thread. The explanation for that is that loadUserPhotos is a nonisolated and async operate.

Which means that when you could have code as follows, the compiler will complain about sending a non-sendable occasion of NetworkingClient throughout actor boundaries:

struct SomeView: View {
  let community = NetworkingClient()

  var physique: some View {
    Textual content("Good day, world")
      .activity { await getData() }
  }

  func getData() async {
    do {
      // sending 'self.community' dangers inflicting knowledge races
      let images = attempt await community.loadUserPhotos()
    } catch {
      // ...
    }
  }
}

While you take a better take a look at the error, the compiler will clarify:

sending important actor-isolated ‘self.community’ to nonisolated occasion technique ‘loadUserPhotos()’ dangers inflicting knowledge races between nonisolated and important actor-isolated makes use of

This error is similar to one that you simply’d get when sending a important actor remoted worth right into a sendable closure.

The issue with this code is that loadUserPhotos runs in its personal isolation context. Which means that it is going to run concurrently with no matter the principle actor is doing.

Since our occasion of NetworkingClient is created and owned by the principle actor we will entry and mutate our networking occasion whereas loadUserPhotos is operating in its personal isolation context. Since that operate has entry to self, it implies that we will have two isolation contexts entry the identical occasion of NetworkingClient at the very same time.

And as we all know, a number of isolation contexts accessing the identical object can result in knowledge races if the thing isn’t sendable.

The distinction between an async and non-async operate that’s nonisolated like loadUserPhotos is that the non-async operate would run on the caller’s actor. So if we name a nonisolated async operate from the principle actor then the operate will run on the principle actor. Once we name a nonisolated async operate from a spot that’s not on the principle actor, then the known as operate will not run on the principle actor.

Swift 6.2 goals to repair this with a brand new default for nonisolated capabilities.

Understanding nonisolated(nonsending)

The habits in Swift 6.1 and earlier is inconsistent and complicated for people, so in Swift 6.2, async capabilities will undertake a brand new default for nonisolated capabilities known as nonisolated(nonsending). You don’t have to put in writing this manually; it’s the default so each nonisolated async operate will probably be nonsending except you specify in any other case.

When a operate is nonisolated(nonsending) it implies that the operate gained’t cross actor boundaries. Or, in a extra sensible sense, a nonisolated(nonsending) operate will run on the caller’s actor.

So once we opt-in to this characteristic by enabling the NonisolatedNonsendingByDefault upcoming characteristic, the code we wrote earlier is totally high-quality.

The explanation for that’s that loadUserPhotos() would now be nonisolated(nonsending) by default, and it could run its operate physique on the principle actor as an alternative of operating it on the cooperative thread pool.

Let’s check out some examples, lets? We noticed the next instance earlier:

class NetworkingClient {
  func loadUserPhotos() async throws -> [Photo] {
    // ...
  }
}

On this case, loadUserPhotos is each nonisolated and async. Which means that the operate will obtain a nonisolated(nonsending) remedy by default, and it runs on the caller’s actor (if any). In different phrases, in the event you name this operate on the principle actor it is going to run on the principle actor. Name it from a spot that’s not remoted to an actor; it is going to run away from the principle thread.

Alternatively, we would have added a @MainActor declaration to NetworkingClient:

@MainActor
class NetworkingClient {
  func loadUserPhotos() async throws -> [Photo] {
    return [Photo()]
  }
}

This makes loadUserPhotos remoted to the principle actor so it is going to all the time run on the principle actor, regardless of the place it’s known as from.

Then we would even have the principle actor annotation together with nonisolated on loadUserPhotos:

@MainActor
class NetworkingClient {
  nonisolated func loadUserPhotos() async throws -> [Photo] {
    return [Photo()]
  }
}

On this case, the brand new default kicks in despite the fact that we didn’t write nonisolated(nonsending) ourselves. So, NetworkingClient is important actor remoted however loadUserPhotos is just not. It would inherit the caller’s actor. So, as soon as once more if we name loadUserPhotos from the principle actor, that’s the place we’ll run. If we name it from another place, it is going to run there.

So what if we wish to make it possible for our operate by no means runs on the principle actor? As a result of thus far, we’ve solely seen potentialities that might both isolate loadUserPhotos to the principle actor, or choices that might inherit the callers actor.

Working code away from any actors with @concurrent

Alongside nonisolated(nonsending), Swift 6.2 introduces the @concurrent key phrase. This key phrase will permit you to write capabilities that behave in the identical method that your code in Swift 6.1 would have behaved:

@MainActor
class NetworkingClient {
  @concurrent
  nonisolated func loadUserPhotos() async throws -> [Photo] {
    return [Photo()]
  }
}

By marking our operate as @concurrent, we make it possible for we all the time depart the caller’s actor and create our personal isolation context.

The @concurrent attribute ought to solely be utilized to capabilities which can be nonisolated. So for instance, including it to a way on an actor gained’t work except the strategy is nonisolated:

actor SomeGenerator {
  // not allowed
  @concurrent
  func randomID() async throws -> UUID {
    return UUID()
  }

  // allowed
  @concurrent
  nonisolated func randomID() async throws -> UUID {
    return UUID()
  }
}

Observe that on the time of writing each instances are allowed, and the @concurrent operate that’s not nonisolated acts prefer it’s not remoted at runtime. I count on that this can be a bug within the Swift 6.2 toolchain and that this can change because the proposal is fairly clear about this.

How and when must you use NonisolatedNonSendingByDefault

In my view, opting in to this upcoming characteristic is a good suggestion. It does open you as much as a brand new method of working the place your nonisolated async capabilities inherit the caller’s actor as an alternative of all the time operating in their very own isolation context, nevertheless it does make for fewer compiler errors in observe, and it truly helps you do away with a complete bunch of important actor annotation primarily based on what I’ve been in a position to attempt thus far.

I’m an enormous fan of lowering the quantity of concurrency in my apps and solely introducing it after I wish to explicitly accomplish that. Adopting this characteristic helps quite a bit with that. Earlier than you go and mark every little thing in your app as @concurrent simply to make sure; ask your self whether or not you actually must. There’s most likely no want, and never operating every little thing concurrently makes your code, and its execution quite a bit simpler to purpose about within the large image.

That’s very true while you additionally undertake Swift 6.2’s second main characteristic: defaultIsolation.

Exploring Swift 6.2’s defaultIsolation choices

In Swift 6.1 your code solely runs on the principle actor while you inform it to. This could possibly be because of a protocol being @MainActor annotated otherwise you explicitly marking your views, view fashions, and different objects as @MainActor.

Marking one thing as @MainActor is a reasonably frequent answer for fixing compiler errors and it’s as a rule the correct factor to do.

Your code actually doesn’t must do every little thing asynchronously on a background thread.

Doing so is comparatively costly, typically doesn’t enhance efficiency, and it makes your code quite a bit more durable to purpose about. You wouldn’t have written DispatchQueue.international() in every single place earlier than you adopted Swift Concurrency, proper? So why do the equal now?

Anyway, in Swift 6.2 we will make operating on the principle actor the default on a package deal degree. It is a characteristic launched by SE-0466.

This implies that you would be able to have UI packages and app targets and mannequin packages and so forth, robotically run code on the principle actor except you explicitly opt-out of operating on important with @concurrent or by means of your personal actors.

Allow this characteristic by setting defaultIsolation in your swiftSettings or by passing it as a compiler argument:

swiftSettings: [
    .defaultIsolation(MainActor.self),
    .enableExperimentalFeature("NonisolatedNonsendingByDefault")
]

You don’t have to make use of defaultIsolation alongside NonisolatedNonsendingByDefault however I did like to make use of each choices in my experiments.

At present you may both go MainActor.self as your default isolation to run every little thing on important by default, or you need to use nil to maintain the present habits (or don’t go the setting in any respect to maintain the present habits).

When you allow this characteristic, Swift will infer each object to have an @MainActor annotation except you explicitly specify one thing else:

@Observable
class Particular person {
  var myValue: Int = 0
  let obj = TestClass()

  // This operate will _always_ run on important 
  // if defaultIsolation is about to important actor
  func runMeSomewhere() async {
    MainActor.assertIsolated()
    // do some work, name async capabilities and so forth
  }
}

This code comprises a nonisolated async operate. Which means that, by default, it could inherit the actor that we name runMeSomewhere from. If we name it from the principle actor that’s the place it runs. If we name it from one other actor or from no actor, it runs away from the principle actor.

This most likely wasn’t supposed in any respect.

Possibly we simply wrote an async operate in order that we might name different capabilities that wanted to be awaited. If runMeSomewhere doesn’t do any heavy processing, we most likely need Particular person to be on the principle actor. It’s an observable class so it most likely drives our UI which implies that just about all entry to this object ought to be on the principle actor anyway.

With defaultIsolation set to MainActor.self, our Particular person will get an implicit @MainActor annotation so our Particular person runs all its work on the principle actor.

Let’s say we wish to add a operate to Particular person that’s not going to run on the principle actor. We are able to use nonisolated similar to we’d in any other case:

// This operate will run on the caller's actor
nonisolated func runMeSomewhere() async {
  MainActor.assertIsolated()
  // do some work, name async capabilities and so forth
}

And if we wish to make sure that we’re by no means on the principle actor:

// This operate will run on the caller's actor
@concurrent
nonisolated func runMeSomewhere() async {
  MainActor.assertIsolated()
  // do some work, name async capabilities and so forth
}

We have to opt-out of this important actor inference for each operate or property that we wish to make nonisolated; we will’t do that for all the sort.

After all, your personal actors won’t all of a sudden begin operating on the principle actor and kinds that you simply’ve annotated with your personal international actors aren’t impacted by this transformation both.

Do you have to opt-in to defaultIsolation?

It is a powerful query to reply. My preliminary thought is “sure”. For app targets, UI packages, and packages that primarily maintain view fashions I positively suppose that going important actor by default is the correct selection.

You possibly can nonetheless introduce concurrency the place wanted and it is going to be far more intentional than it could have been in any other case.

The truth that total objects will probably be made important actor by default looks like one thing that would possibly trigger friction down the road however I really feel like including devoted async packages could be the way in which to go right here.

The motivation for this selection present makes loads of sense to me and I feel I’ll wish to attempt it out for a bit earlier than making up my thoughts absolutely.