Sending vs Sendable in Swift – Donny Wals

With Swift 6, we’ve got a wholly new model of the language that has all types of knowledge race protections built-in. Most of those protections had been round with Swift 5 in a technique or one other and in Swift 6 they’ve refined, up to date, improved, and expanded these options, making them necessary. So in Swift 5 you possibly can get away with sure issues the place in Swift 6 these at the moment are compiler errors.

Swift 6 additionally introduces a bunch of recent options, one among these is the sending key phrase. Sending carefully pertains to Sendable, however they’re fairly totally different by way of why they’re used, what they’ll do, and which issues they have an inclination to resolve.

On this submit, I want to discover the similarities and variations between Sendable and sending. By the tip of this submit, you’ll perceive why the Swift crew determined to alter the closures that you simply cross to duties, continuations, and process teams to be sending as an alternative of @Sendable.

In the event you’re not totally updated on Sendable, I extremely suggest that you simply take a look at my submit on Sendable and @Sendable closures. On this submit, it is most related so that you can perceive the @Sendable closures half as a result of we’ll be taking a look at a comparability between a @Sendable closure and a sending argument.

Understanding the issue that’s solved by sending

In Swift 5, we did not have the sending key phrase. That meant that if we wished to cross a closure or a worth from one place to a different safely, we might try this with the sendable annotation. So, for instance, Activity would have been outlined just a little 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 Activity implies that that closure ought to be secure to name from every other duties or isolation context. In observe, which means no matter we do and seize within that closure have to be secure, or in different phrases, it have to be Sendable.

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

Because of this the code under just isn’t secure in accordance with the Swift 5.10 compiler with strict concurrency warnings enabled.

Be aware that operating the instance under in Xcode 16 with the Swift 6 compiler in Swift 5 mode won’t throw any errors. That is as a result of Activity 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, Activity takes a sending operation.

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

  Activity {
      // Seize of 'isNotSendable' with non-sendable sort 'MyClass' in a `@Sendable` closure
    isNotSendable.depend += 1
  }
}

If you wish to discover this compiler error in a mission that makes use of the Swift 6 compiler, you’ll be able to outline your personal perform that takes a @Sendable closure as an alternative of a Activity:

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

In the event you name that as an alternative of Activity, 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 process which in Swift 5 nonetheless took a @Sendable closure.

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

This drawback 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 within the perform that we’re making a process 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 tip of exampleFunc this occasion is not retained exterior of the Activity closure.

Due to this, there is not any manner that we’ll be passing isolation boundaries right here; No different place than our Activity has entry to our occasion anymore.

That’s the place sending is available in…

Understanding sending arguments

In Swift 6, the crew 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 permits us to cross 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()

  Activity {
    isNotSendable.depend += 1
  }
}

That’s as a result of Activity 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 just isn’t accessed or used after the duty captures it. So whereas the code above is legitimate, we will truly write one thing that’s not legitimate.

For instance:

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

  // Worth of non-Sendable sort ... accessed after being transferred; 
  // later accesses might race
  Activity {
    isNotSendable.depend += 1
  }

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

This alteration to the language permits us to cross non-sendable state right into a Activity, which is one thing that you will typically wish to do. It additionally makes certain that we’re not doing issues which are doubtlessly 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 personal capabilities that take closures that you simply wish to be secure to name from a number of isolation contexts, you’ll wish to mark them as sending.

Defining your personal perform 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 sort, just like the place @escaping would usually go.

In Abstract

You most likely will not be defining your personal sending closures or your personal capabilities that take sending arguments continuously. The Swift crew 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 may discover that Swift 6 means that you can do sure issues that Swift 5 would not will let you do with strict concurrency enabled.

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

I extremely suggest that you simply experiment with the examples on this weblog submit by defining your personal sending and @Sendable closures and seeing how every may be known as and how one can name them from a number of duties. It is also price exploring how and when every choices stops working so that you’re conscious of their limitations.

Additional studying