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

When you begin migrating to the Swift 6 language mode, you may most probably activate strict concurrency first. As soon as you’ve got finished this there might be a number of warings and errors that you will encounter and these errors will be complicated at instances.

I am going to begin by saying that having a strong understanding of actors, sendable, and knowledge races is a big benefit once you wish 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 operating code concurrently. For an in-depth understanding of actors, sendability and knowledge races I extremely suggest that you just check out my Swift Concurrency course which is able to get you entry to a sequence of movies, workouts, and my Sensible Swift Concurrency guide with a single buy.

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

Worth of non-Sendable sort ‘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 sort '@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 somewhat steerage 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 may 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 would possibly really collide with the append inside of the duty. When this occurs, we’ve got an information race and our code would crash.

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

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

This eliminates our knowledge race potential nevertheless it’s additionally probably not reaching our purpose of appending to the array from inside the duty.

The repair right here might be one in all a number of approaches:

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

Finally, most strict concurrency associated points do not have a single resolution that works. It is at all times going to require a case-by-case evaluation of why a sure error seems, and from there it is best to work out an answer.

On this case, we’re taking a mutable object that we’re mutating from inside a process in addition to proper after the place we have outlined the duty. The compiler is warning us that that can most probably trigger an information race and you may want to find out which resolution 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.