Exploring concurrency modifications in Swift 6.2 – Donny Wals

It is no secret that Swift concurrency might be fairly troublesome to study. There are lots of ideas which can be totally different from what you are used to if you have been writing code in GCD. Apple acknowledged this in one in all 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 may primarily change is the place code will run by default.

On this weblog submit, I would really like to try the 2 most important options that may change how your Swift concurrency code works:

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

By the top of this submit it is best to have a fairly good sense of the impression that Swift 6.2 can have in your code, and the way you ought to be transferring ahead till Swift 6.2 is formally obtainable in a future Xcode launch.

Understanding nonisolated(nonsending)

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

For this submit, I’m utilizing an SPM bundle so my Package deal.swift incorporates the next:

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

I’m getting forward of myself although; let’s discuss what nonisolated(nonsending) is, what drawback 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

Once you write async capabilities in Swift 6.1 and earlier, you may 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 might 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("Hiya, world")
      .activity { await getData() }
  }

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

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

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

This error is similar to one that you simply’d get when sending a most 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’ll run concurrently with no matter the principle actor is doing.

Since our occasion of NetworkingClient is created and owned by the principle actor we are able to 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 are able to 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 item 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. After 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 conduct 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 jot down this manually; it’s the default so each nonisolated async operate will likely be nonsending until 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 after we opt-in to this characteristic by enabling the NonisolatedNonsendingByDefault upcoming characteristic, the code we wrote earlier is totally positive.

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

Let’s check out some examples, we could? 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 case you name this operate on the principle actor it’ll run on the principle actor. Name it from a spot that’s not remoted to an actor; it’ll run away from the principle thread.

Alternatively, we’d 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’ll at all times run on the principle actor, irrespective of the place it’s known as from.

Then we’d 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 though we didn’t write nonisolated(nonsending) ourselves. So, NetworkingClient is most important actor remoted however loadUserPhotos shouldn’t be. It’s going to 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’ll run there.

So what if we need to be sure that our operate by no means runs on the principle actor? As a result of to date, we’ve solely seen potentialities that will both isolate loadUserPhotos to the principle actor, or choices that will inherit the callers actor.

Operating code away from any actors with @concurrent

Alongside nonisolated(nonsending), Swift 6.2 introduces the @concurrent key phrase. This key phrase will help you write capabilities that behave in the identical means 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 be sure that we at all times go away 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 technique on an actor gained’t work until 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 anticipate that this can be a bug within the Swift 6.2 toolchain and that it will change because the proposal is fairly clear about this.

How and when do you have to 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 means of working the place your nonisolated async capabilities inherit the caller’s actor as a substitute of at all times operating in their very own isolation context, however it does make for fewer compiler errors in apply, and it truly helps you eliminate a complete bunch of most important actor annotation based mostly on what I’ve been in a position to strive to date.

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

That’s very true if 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 if you inform it to. This may very well be attributable to 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 fairly frequent answer for fixing compiler errors and it’s as a rule the appropriate factor to do.

Your code actually doesn’t have to do all the pieces asynchronously on a background thread.

Doing so is comparatively costly, usually doesn’t enhance efficiency, and it makes your code loads more durable to purpose about. You wouldn’t have written DispatchQueue.world() in all places earlier than you adopted Swift Concurrency, proper? So why do the equal now?

Anyway, in Swift 6.2 we are able to make operating on the principle actor the default on a bundle 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 many others, robotically run code on the principle actor until you explicitly opt-out of operating on most important with @concurrent or by means of your individual 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.

Presently you’ll be able to both go MainActor.self as your default isolation to run all the pieces on most important by default, or you should utilize nil to maintain the present conduct (or don’t go the setting in any respect to maintain the present conduct).

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

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

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

This code incorporates a nonisolated async operate. Which means that, by default, it might 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 may 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 needs 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 need to add a operate to Particular person that’s not going to run on the principle actor. We are able to use nonisolated identical 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 many others
}

And if we need to be certain 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 many others
}

We have to opt-out of this most important actor inference for each operate or property that we need to make nonisolated; we are able to’t do that for your entire kind.

In fact, your individual actors won’t immediately begin operating on the principle actor and kinds that you simply’ve annotated with your individual world actors aren’t impacted by this modification 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 undoubtedly assume that going most important actor by default is the appropriate selection.

You’ll be able to nonetheless introduce concurrency the place wanted and it is going to be way more intentional than it might have been in any other case.

The truth that total objects will likely be made most important actor by default looks like one thing that may 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 lots of sense to me and I feel I’ll need to strive it out for a bit earlier than making up my thoughts absolutely.