What are Sendable and @Sendable closures in Swift? – Donny Wals

Revealed on: September 13, 2022

One of many objectives of the Swift crew with Swift’s concurrency options is to supply a mannequin that permits developer to put in writing secure code by default. Because of this there’s plenty of time and vitality invested into ensuring that the Swift compiler helps builders detect, and forestall entire lessons of bugs and concurrency points altogether.

One of many options that helps you stop information races (a typical concurrency concern) comes within the type of actors which I’ve written about earlier than.

Whereas actors are nice whenever you wish to synchronize entry to some mutable state, they don’t remedy each potential concern you may need in concurrent code.

On this publish, we’re going to take a better take a look at the Sendable protocol, and the @Sendable annotation for closures. By the top of this publish, you need to have a very good understanding of the issues that Sendable (and @Sendable) goal to unravel, how they work, and the way you need to use them in your code.

Understanding the issues solved by Sendable

One of many trickiest facets of a concurrent program is to make sure information consistency. Or in different phrases, thread security. After we move cases of lessons or structs, enum circumstances, and even closures round in an utility that doesn’t do a lot concurrent work, we don’t want to fret about thread security so much. In apps that don’t actually carry out concurrent work, it’s unlikely that two duties try to entry and / or mutate a chunk of state at the very same time. (However not inconceivable)

For instance, you may be grabbing information from the community, after which passing the obtained information round to a few features in your principal thread.

Because of the nature of the principle thread, you’ll be able to safely assume that your entire code runs sequentially, and no two processes in your utility shall be engaged on the identical referencea on the identical time, probably creating an information race.

To briefly outline an information race, it’s when two or extra elements of your code try to entry the identical information in reminiscence, and not less than one among these accesses is a write motion. When this occurs, you’ll be able to by no means make certain concerning the order by which the reads and writes occur, and you may even run into crashes for unhealthy reminiscence accesses. All in all, information races are not any enjoyable.

Whereas actors are a improbable strategy to construct objects that accurately isolate and synchronize entry to their mutable state, they will’t remedy all of our information races. And extra importantly, it may not be cheap so that you can rewrite your entire code to utilize actors.

Contemplate one thing like the next code:

class FormatterCache {
    var formatters = [String: DateFormatter]()

    func formatter(for format: String) -> DateFormatter {
        if let formatter = formatters[format] {
            return formatter

        let formatter = DateFormatter()
        formatter.dateFormat = format
        formatters[format] = formatter

        return formatter

func performWork() async {
    let cache = FormatterCache()
    let possibleFormatters = ["YYYYMMDD", "YYYY", "YYYY-MM-DD"]

    await withTaskGroup(of: Void.self) { group in
        for _ in 0..<10 {
            group.addTask {
                let format = possibleFormatters.randomElement()!
                let formatter = cache.formatter(for: format)

On first look, this code may not look too unhealthy. We’ve got a category that acts as a easy cache for date formatters, and we’ve a job group that can run a bunch of code in parallel. Every job will seize a random date format from the checklist of potential format and asks the cache for a date formatter.

Ideally, we count on the formatter cache to solely create one date formatter for every date format, and return a cached formatter after a formatter has been created.

Nonetheless, as a result of our duties run in parallel there’s an opportunity for information races right here. One fast repair could be to make our FormatterCache an actor and this might remedy our potential information race. Whereas that will be a very good resolution (and really the most effective resolution if you happen to ask me) the compiler tells us one thing else once we attempt to compile the code above:

Seize of ‘cache’ with non-sendable kind ‘FormatterCache’ in a @Sendable closure

This warning is making an attempt to inform us that we’re doing one thing that’s probably harmful. We’re capturing a price that can not be safely handed by concurrency boundaries in a closure that’s imagined to be safely handed by concurrency boundaries.

With the ability to be safely handed by concurrency boundaries primarily signifies that a price may be safely accessed and mutated from a number of duties concurrently with out inflicting information races. Swift makes use of the Sendable protocol and the @Sendable annotation to speak this thread-safety requirement to the compiler, and the compiler can then examine whether or not an object is certainly Sendable by assembly the Sendable necessities.

What these necessities are precisely will range a bit of relying on the kind of objects you cope with. For instance, actor objects are Sendable by default as a result of they’ve information security built-in.

Let’s check out different forms of objects to see what their Sendable necessities are precisely.

Sendable and worth varieties

In Swift, worth varieties present plenty of thread security out of the field. If you move a price kind from one place to the following, a duplicate is created which signifies that every place that holds a duplicate of your worth kind can freely mutate its copy with out affecting different elements of the code.

This an enormous good thing about structs over lessons as a result of they permit use to cause regionally about our code with out having to contemplate whether or not different elements of our code have a reference to the identical occasion of our object.

Due to this conduct, worth varieties like structs an enums are Sendable by default so long as all of their members are additionally Sendable.

Let’s take a look at an instance:

// This struct is just not sendable
struct Film {
    personal let dateFormatter: DateFormatter = {
        let formatter = DateFormatter()
        formatter.dateFormat = "YYYY"
        return formatter

    let releaseDate = Date()
    var formattedReleaseDate: String {
        dateFormatter.string(from: releaseDate)

// This struct is sendable
struct Film {
    var formattedReleaseDate = "2022"

I do know that this instance is a bit of bizarre; they don’t have the very same performance however that’s not the purpose.

The purpose is that the primary struct does not likely maintain mutable state; all of its properties are both constants, or they’re computed properties. Nonetheless, Date and DateFormatter each are lessons and so they aren’t Sendable. Since our Film struct doesn’t maintain a duplicate of the Date or DateFormatter, all copies of Film could be trying on the identical cases of the Date and DateFormatter, which signifies that we may be information races if a number of Film copies would try to, for instance, set a unique dateFormat on the DateFormatter.

The second struct solely holds Sendable state. String is Sendable and because it’s the one property outlined on Film, film can be Sendable.

The rule right here is that every one worth varieties are Sendable so long as their members are additionally Sendable.

Sendable and lessons

Whereas each structs and actors are implicitly Sendable, lessons should not. That’s as a result of lessons are so much much less secure by their nature; everyone that receives an occasion of a category really receives a reference to that occasion. Because of this a number of locations in your code maintain a reference to the very same reminiscence location and all mutations you make on a category occasion are shared amongst everyone that holds a reference to that class occasion.

That doesn’t imply we will’t make our lessons Sendable, it simply signifies that we have to add the conformance manually, and manually be sure that our lessons are literally Sendable.

We are able to make our lessons Sendable by including conformance to the Sendable protocol:

closing class Film: Sendable {
    let formattedReleaseDate = "2022"

The necessities for a category to be Sendable are just like these for a struct.

For instance, a category can solely be Sendable if all of its members are Sendable. Because of this they need to both be Sendable lessons, worth varieties, or actors. This requirement is an identical to the necessities for Sendable structs.

Along with this requirement, your class should be closing. Inheritance may break your Sendable conformance if a subclass provides incompatible overrides or options. For that reason, solely closing lessons may be made Sendable.

Lastly, your Sendable class mustn’t maintain any mutable state. Mutable state would imply that a number of duties can try to mutate your state, main to a knowledge race.

Nonetheless, there are cases the place we would know a category or struct is secure to be handed throughout concurrency boundaries even when the compiler can’t proof it.

In these circumstances, we will fall again on unchecked Sendable conformance.

Unchecked Sendable conformance

If you’re working with codebases that predate Swift Concurrency, likelihood is that you simply’re slowly working your method by your app with a purpose to introduce concurrency options. Because of this a few of your objects might want to work in your async code, in addition to in your sync code. Because of this utilizing actor to isolate mutable state in a reference kind may not work so that you’re caught with a category that may’t conform to Sendable. For instance, you may need one thing like the next code:

class FormatterCache {
    privatevar formatters = [String: DateFormatter]()
    personal let queue = DispatchQueue(label: "com.dw.FormatterCache.(UUID().uuidString)")

    func formatter(for format: String) -> DateFormatter {
        return queue.sync {
            if let formatter = formatters[format] {
                return formatter

            let formatter = DateFormatter()
            formatter.dateFormat = format
            formatters[format] = formatter

            return formatter

This formatter cache makes use of a serial queue to make sure synchronized entry to its formatters dictionary. Whereas the implementation isn’t ultimate (we may very well be utilizing a barrier or possibly even a plain outdated lock as a substitute), it really works. Nonetheless, we will’t add Sendable conformance to our class as a result of formatters isn’t Sendable.

To repair this, we will add @unchecked Sendable conformance to our FormatterCache:

class FormatterCache: @unchecked Sendable {
    // implementation unchanged

By including this @unchecked Sendable we’re instructing the compiler to imagine that our FormatterCache is Sendable even when it doesn’t meet the entire necessities.

Having this characteristic in our toolbox is extremely helpful whenever you’re slowly phasing Swift Concurrency into an current challenge, however you’ll wish to suppose twice, or possibly even 3 times, whenever you’re reaching for @unchecked Sendable. It is best to solely use this characteristic whenever you’re actually sure that your code is definitely secure for use in a concurrent setting.

Utilizing @Sendable on closures

There’s one final place the place Sendable comes into play and that’s on features and closures.

Plenty of closures in Swift Concurrency are annotated with the @Sendable annotation. For instance, right here’s what the declaration for TaskGroup‘s addTask appears to be like like:

public mutating func addTask(precedence: TaskPriority? = nil, operation: @escaping @Sendable () async -> ChildTaskResult)

The operation closure that’s handed to addTask is marked with @Sendable. Because of this any state that the closure captures should be Sendable as a result of the closure may be handed throughout concurrency boundaries.

In different phrases, this closure will run in a concurrent method so we wish to guarantee that we’re not by chance introducing an information race. If all state captured by the closure is Sendable, then we all know for positive that the closure itself is Sendable. Or in different phrases, we all know that the closure can safely be handed round in a concurrent setting.

Tip: to study extra about closures in Swift, check out my publish that explains closures in nice element.


On this publish, you’ve discovered concerning the Sendable and @Sendable options of Swift Concurrency. You discovered why concurrent applications require additional security round mutable state, and state that’s handed throughout concurrency boundaries with a purpose to keep away from information races.

You discovered that structs are implicitly Sendable if all of their members are Sendable. You additionally discovered that lessons may be made Sendable so long as they’re closing, and so long as all of their members are additionally Sendable.

Lastly, you discovered that the @Sendable annotation for closures helps the compiler be sure that all state captured in a closure is Sendable and that it’s secure to name that closure in a concurrent context.

I hope you’ve loved this publish. If in case you have any questions, suggestions, or solutions to assist me enhance the reference then be at liberty to achieve out to me on Twitter.

Leave a Reply