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 more than likely activate strict concurrency first. As soon as you have accomplished this there can be a number of warings and errors that you’re going to encounter and these errors could be complicated at occasions.

I am going to begin by saying that having a stable understanding of actors, sendable, and knowledge races is a large benefit whenever you need to undertake the Swift 6 language mode. Just about the entire warnings you may get in strict concurrency mode will let you know about potential points associated to working 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 collection of movies, workouts, and my Sensible Swift Concurrency e book with a single buy.

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

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]()

Process {
  // 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 affords a little bit 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 Process. You may see how we’re appending to the array each within the duty in addition to exterior of it.

Swift is telling us that we’re doubtlessly inflicting knowledge races right here as a result of our append on myArray after the duty may really 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 replica for our activity when it is created:

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

This eliminates our knowledge race potential nevertheless it’s additionally not likely attaining our objective of appending to the array from within the duty.

The repair right here could possibly be one among 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 method fully
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 must work out 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 more than likely 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 verify we obtain correct isolation and stop future knowledge races.