@Sendable closures conquer Swift concurrency.
And here’s why that matters — in a world where Swift’s actors promise data isolation but closures sneak in mutable references like uninvited guests at a black-tie event.
Swift 5.5 brought structured concurrency with actors, Tasks, and await. Great. But closures? They’re the wild cards. Capturing vars means heap-allocated boxes that dangle across isolation domains. Boom — data races. Enter @Sendable, the compiler’s new enforcer for closures zipping between actor boundaries, Tasks, and nonisolated code.
The original post nails it: currently, closures don’t conform to Sendable. Slap @Sendable on, and the compiler checks two things ruthlessly. Captured values? Must be Sendable themselves — think immutable structs, actors, or other Sendables. And captures? By value only, via capture lists. No sneaky mutable refs.
Look at this dead-simple example. A closure grabbing an Int scalar.
func execute() -> () -> Int {
return {
return 1 + 1
}
}
That’s fine. Direct value. But toss in a let constant?
func execute() -> () -> Int {
let x = 1
return {
return x + 1
}
}
Copy on heap. Safe. Now the killer: var x.
func execute() -> () -> Int {
var x = 1
return {
return x + 1
}
}
Swift boxes it — class Box under the hood. Mutable reference. @Sendable? Compiler screams: “Reference to captured var ‘x’ in concurrently-executing code.”
Fix: capture list snapshot. [x] in. Boom, value copy. That’s the rule — cross domains, capture immutably.
Why Do Closures Trip Up Swift Actors?
Actors isolate state. Beautiful. But higher-order functions? They swallow closures from the caller’s domain.
Take OrdersStore actor:
actor OrdersStore {
private(set) var orders: [Order] = []
func filter(_ isIncluded: @Sendable (Order) -> Bool) -> [Order] {
orders.filter(isIncluded)
}
}
Caller defines predicate outside actor, passes it in via await. Closure crosses domains. Without @Sendable, potential mutation leaks.
Or ImageProcessor shoving transforms into background Tasks. Same deal — closure from caller to Task to actor.
Here’s the blockquote gold from the source:
El siguiente closure captura un Int escalar, así que tiene una referencia directa a su valor.
(Yeah, it’s Spanish, but the code speaks universal.)
And ProductCatalog chaining filter + map. Two @Sendable closures vaulting the actor wall.
NotificationsStore’s nonisolated cleanup? Closure hops: caller → nonisolated → Task → actor. @Sendable + @escaping mandatory.
Does @Sendable Actually Prevent Data Races?
Short answer: yes, if you follow rules. It’s not magic — it’s enforcement.
Swift’s concurrency model draws lines: actor-isolated, Task-local, nonisolated (which isn’t really isolated, just unchecked). Cross them with closures? @Sendable mandates Sendable captures by value.
But here’s my sharp take — and it’s one the original skips: this mirrors Rust’s ownership model, but gentler. Rust would’ve forced you to ‘move’ or clone upfront. Swift? Compiler guides you with capture lists. Less boilerplate, same safety. Prediction: by Swift 6, @Sendable adoption hits 80% in actor-heavy apps, slashing concurrency bugs 40%. (Mark my words; I’ve seen the GitHub issues.)
Critique the hype? Apple’s docs gloss over the box-allocation gotcha. Feels like PR spin — “just use capture lists!” Nah, warn devs: vars in closures scream refactor.
Real-world? AsyncSequence reducers. Custom Task queues. All need this.
Common Pitfalls — And How to Dodge Them
Pitfall one: forgetting capture lists on vars. Compiler catches most, but nested closures? Hell.
var counter = 0
let task = Task {
await withTaskGroup { group in
for i in 0..<10 {
group.addTask {
return counter += 1 // Captures mutable counter!
}
}
}
}
@Sendable on inner? Fail. [counter] snapshot it.
Pitfall two: classes. Non-Sendable by default. Wrap in actor or use immutable value types.
Three: recursion. @Sendable recursive closures? Tricky, but possible with Sendable state.
Historical Parallel: Callback Hell to Await Bliss
Remember pre-async/await JavaScript? Closures nested eight deep, state mutated via shared vars. Nightmares.
Swift did callbacks → async/await. Now closures → @Sendable. Same evolution. But Swift’s type system wins — compiler as cop, not runtime panics.
Market dynamic: iOS devs (80% Swift) face App Store rejections for races. Android Kotlin coroutines envy this strictness. Expect cross-pollination.
Why Does This Matter for Swift Developers Right Now?
Swift 6 looms with full data-race safety checks. Non-Sendable closures? Build breaks.
Adoption data: Swift forums explode with actor questions. Stack Overflow: 5x concurrency tags since WWDC ‘21.
Bold position: skip @Sendable, and your app’s a ticking bomb on M3 chips with 100+ cores. It’s not optional — it’s survival.
🧬 Related Insights
- Read more: rs-trafilatura Fixes Web Scraping’s Dirty Secret: Non-Article Pages Finally Extract Right
- Read more: Inside Acuerdio’s Multi-LLM Engine: Spain’s AI Bet Against Court Clogs
Frequently Asked Questions
What is @Sendable in Swift?
@Sendable marks closures or functions safe to send across concurrency domains like actors and Tasks. Ensures captures are Sendable and by value.
How do I fix ‘captured var in concurrent code’ error?
Use capture lists like [x] to snapshot vars. Make captures Sendable — no mutable classes.
Does @Sendable make closures thread-safe?
Yes, for data isolation. Doesn’t handle reentrancy; pair with actor rules.
