Sending vs Sendable in Swift – Donny Wals

Understanding the issue that’s solved by sending

In Swift 5, we did not have the sending key phrase. That meant that if we needed to go a closure or a worth from one place to a different safely, we’d try this with the sendable annotation. So, for instance, Job would have been outlined a little bit bit like this in Swift 5.

public init(
  precedence: TaskPriority? = nil,
  operation: @Sendable @escaping () async -> Success
)

This initializer is copied from the Swift repository with some annotations stripped for simplicity.

Discover that the operation argument takes a @Sendable closure.

Taking a @Sendable closure for one thing like a Job signifies that that closure must be secure to name from another duties or isolation context. In apply, because of this no matter we do and seize inside that closure should be secure, or in different phrases, it should be Sendable.

So, a @Sendable closure can primarily solely seize Sendable issues.

Which means the code under isn’t secure in line with the Swift 5.10 compiler with strict concurrency warnings enabled.

Word that operating the instance under in Xcode 16 with the Swift 6 compiler in Swift 5 mode is not going to throw any errors. That is as a result of Job has modified its operation to be sending as an alternative of @Sendable at a language degree no matter language mode.

So, even in Swift 5 language mode, Job takes a sending operation.

// The instance under requires the Swift 5 COMPILER to fail
// Utilizing the Swift 5 language mode isn't sufficient
func exampleFunc() {
  let isNotSendable = MyClass()

  Job {
      // Seize of 'isNotSendable' with non-sendable kind 'MyClass' in a `@Sendable` closure
    isNotSendable.rely += 1
  }
}

If you wish to discover this compiler error in a mission that makes use of the Swift 6 compiler, you possibly can outline your individual operate that takes a @Sendable closure as an alternative of a Job:

public func sendableClosure(
  _ closure: @Sendable () -> Void
  ) {
  closure()
}

For those who name that as an alternative of Job, you’ll see the compiler error talked about earlier.

The compiler error is right. We’re taking one thing that is not sendable and passing it right into a job which in Swift 5 nonetheless took a @Sendable closure.

The compiler does not like that as a result of the compiler says, “If it is a sendable closure, then it should be secure to name this from a number of isolation contexts, and if we’re capturing a non-sendable class, that isn’t going to work.”

This downside is one thing that you’d run into often, particularly with @Sendable closures.

Our particular utilization right here is completely secure although. We’re creating an occasion of MyClass inside the operate that we’re making a job or passing that occasion of MyClass into the duty.

After which we’re by no means accessing it exterior of the duty or after we make the duty anymore as a result of by the top of exampleFunc this occasion is now not retained exterior of the Job closure.

Due to this, there isn’t any approach that we’ll be passing isolation boundaries right here; No different place than our Job has entry to our occasion anymore.

That’s the place sending is available in…

Understanding sending arguments

In Swift 6, the workforce added a characteristic that enables us to inform the compiler that we intend to seize no matter non-sendable state we’d obtain and do not wish to entry it elsewhere after capturing it.

This enables us to go non-sendable objects right into a closure that must be secure to name throughout isolation contexts.

In Swift 6, the code under is completely legitimate:

func exampleFunc() async {
  let isNotSendable = MyClass()

  Job {
    isNotSendable.rely += 1
  }
}

That’s as a result of Job had its operation modified from being @Sendable to one thing that appears a bit as follows:

public init(
  precedence: TaskPriority? = nil,
  operation: sending @escaping () async -> Success
)

Once more, it is a simplified model of the particular initializer. The purpose is so that you can see how they changed @Sendable with sending.

As a result of the closure is now sending as an alternative of @sendable, the compiler can examine that this occasion of MyClass that we’re passing into the duty isn’t accessed or used after the duty captures it. So whereas the code above is legitimate, we are able to truly write one thing that’s now not legitimate.

For instance:

func exampleFunc() async {
  let isNotSendable = MyClass()

  // Worth of non-Sendable kind ... accessed after being transferred; 
  // later accesses might race
  Job {
    isNotSendable.rely += 1
  }

  // Entry can occur concurrently
  print(isNotSendable.rely)
} 

This transformation to the language permits us to go non-sendable state right into a Job, which is one thing that you’re going to generally wish to do. It additionally makes certain that we’re not doing issues which can be probably unsafe, like accessing non-sendable state from a number of isolation contexts, which is what occurs within the instance above.

If you’re defining your individual capabilities that take closures that you just wish to be secure to name from a number of isolation contexts, you’ll wish to mark them as sending.

Defining your individual operate that takes a sending closure appears as follows:

public func sendingClosure(
  _ closure: sending () -> Void
) {
  closure()
}

The sending key phrase is added as a prefix to the closure kind, just like the place @escaping would usually go.

In Abstract

You in all probability will not be defining your individual sending closures or your individual capabilities that take sending arguments often. The Swift workforce has up to date the initializers for duties, indifferent duties, the continuation APIs, and the duty group APIs to take sending closures as an alternative of @Sendable closures. Due to this, you will discover that Swift 6 means that you can do sure issues that Swift 5 would not permit you to do with strict concurrency enabled.

I believe it’s actually cool to know and perceive how sending and @Sendable work.

I extremely advocate that you just experiment with the examples on this weblog publish by defining your individual sending and @Sendable closures and seeing how every might be referred to as and how one can name them from a number of duties. It is also value exploring how and when every choices stops working so that you’re conscious of their limitations.

Additional studying