Fixing “Changing non-sendable perform worth could introduce information races” in Swift

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

I will begin by saying that having a stable understanding of actors, sendable, and information races is a big benefit whenever you need to undertake the Swift 6 language mode. Just about all the warnings you will 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 information races I extremely advocate that you simply check out my Swift Concurrency course which is able to get you entry to a sequence of movies, workout routines, and my Sensible Swift Concurrency e book with a single buy.

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

Changing non-sendable perform worth could introduce information races

Often the warning is a little more detailed, for instance in a mission I labored on this was the complete warning:

Changing non-sendable perform worth to ‘@Sendable (Information?, URLResponse?, (any Error)?) -> Void’ could introduce information races

This warning (or error within the Swift 6 language mode) tells you that you simply’re making an attempt to move a non-sendable closure or perform to a spot that expects one thing that is @Sendable. For comfort I’ll solely use the time period closure however this is applicable equally to features.

Take into account a perform that is outlined as follows:

func performNetworkCall(_ completion: @escaping @Sendable (Information?, URLResponse?, (any Error)?) -> Void) {
    // ...
}

This perform ought to be known as with a closure that is @Sendable to guarantee that we’re not introducting information races in our code. Once we try to name this perform with a closure that is not @Sendable the compiler will complain:

var notSendable: (Information?, URLResponse?, (any Error?)) -> Void = { information, response, error in 
    // ...
}

// Changing non-sendable perform worth to '@Sendable (Information?, URLResponse?, (any Error)?) -> Void' could introduce information races
performNetworkCall(notSendable)

The compiler is unable to ensure that our closure is secure to be known as in a unique actor, process, or different isolation context. So it tells us that we have to repair this.

Often, the repair for this error is to mark your perform or closure as @Sendable:

var notSendable: @Sendable (Information?, URLResponse?, (any Error?)) -> Void = { information, response, error in 
    // ...
}

Now the compiler is aware of that we intend on our closure to be Sendable and it’ll carry out checks to guarantee that it’s. We’re now additionally allowed to move this closure to the performNetworkCall technique that you simply noticed earlier.

If you would like to be taught extra about Sendable and @Sendable take a look at my course or learn a abstract of the subject proper right here.