Fixing “Worth of non-Sendable kind accessed after being transferred; later accesses may race;” – Donny Wals

When you begin migrating to the Swift 6 language mode, you may probably activate strict concurrency first. As soon as you have achieved this there can be a number of warings and errors that you will encounter and these errors could be complicated at occasions.

I am going to begin by saying that having a strong understanding of actors, sendable, and knowledge races is a big benefit if you need to undertake the Swift 6 language mode. Just about all the warnings you may get in strict concurrency mode will inform you about potential points associated to working code concurrently. For an in-depth understanding of actors, sendability and knowledge races I extremely advocate that you just check out my Swift Concurrency course which is able to get you entry to a collection of movies, workouts, and my Sensible Swift Concurrency ebook with a single buy.

WIth that out of the way in which, let’s check out the next warning that you just may encounter in your venture:

Worth of non-Sendable kind ‘MyType’ accessed after being transferred; later accesses may race;

For instance, the next code produces such an error:

var myArray = [Int]()

Job {
  // Worth of non-Sendable kind '@remoted(any) @async @callee_guaranteed @substituted <τ_0_0> () -> @out τ_0_0 for <()>' accessed after being transferred; later accesses may race;
  myArray.append(1)
}

myArray.append(2)

Xcode presents a little bit steering as to what that error is telling us:

Entry can occur concurrently

In different phrases, the compiler is telling us that we’re accessing myArray after we have “transferred” that property to our Job. You possibly can see how we’re appending to the array each inside the duty in addition to exterior of it.

Swift is telling us that we’re probably inflicting knowledge races right here as a result of our append on myArray after the duty may truly collide with the append inside of the duty. When this occurs, we’ve got a knowledge race and our code would crash.

The repair right here could be to explicitly make a duplicate for our activity when it is created:

Job { [myArray] in
  var myArray = myArray
  myArray.append(1)
}

This eliminates our knowledge race potential but it surely’s additionally not likely reaching our aim of appending to the array from inside the duty.

The repair right here could possibly be one in every of a number of approaches:

1. You possibly can wrapp your array in an actor to make sure correct isolation and synchronization
2. You possibly can rework your strategy totally
3. International actors could possibly be helpful right here relying on the construction of your code

In the end, most strict concurrency associated points haven’t got a single answer that works. It is at all times going to require a case-by-case evaluation of why a sure error seems, and from there you need to determine an answer.

On this case, we’re taking a mutable object that we’re mutating from inside a activity in addition to proper after the place we have outlined the duty. The compiler is warning us that that can probably trigger a knowledge race and you will want to find out which answer works for you. My first try at fixing this could be to wrap the mutable state in an actor to ensure we obtain correct isolation and stop future knowledge races.