Changes in Task, @Sendable, and Region-Based Isolation in Swift 6

🔍 Error in Swift 5

In Swift 5, you may have tried code like this:

swift
func runTheExample() async throws {
    let user = User()
    Task {
        try await sendAnalyticsEvents(for: user)
    }
}

Looks harmless, right? But in Swift 5, the compiler would complain:

Why?

Because Task in Swift 5 took an @Sendable closure by default. If you captured a non-Sendable type (like most class instances), you'd hit a wall. You had to explicitly mark types as Sendable, or refactor to avoid the capture.

swift
var closure: @Sendable () async throws -> Void = {
    print(user.name) // ❌ Compilation error
}

✅ What Changed in Swift 6

Swift 6 introduces region-based isolation. This change allows Task to safely capture non-Sendable values as long as the compiler can verify they don’t escape the closure.

Now the same code compiles:

swift
func runTheExample() async throws {
    let user = User()
    Task {
        try await sendAnalyticsEvents(for: user) // ✅ Works in Swift 6!
    }
}

Swift understands that user only lives within the closure's lifetime. It doesn't leak across concurrency boundaries.

📦 Sendable objects in Swift

• It's safe to use concurrently
• It can cross isolation boundaries
• The compiler enforces these guarantees

✅ ✅ Actors are always Sendable

You can safely send actors between concurrency regions.

✅ Structs are Sendable if:

• All their members are Sendable
• They explicitly conform to Sendable (for public types)

🧱 Examples of Sendable Types

✅ A Sendable Struct

swift
struct SendableStruct {
    let id = UUID()
    var count = 0
}

❌ A Non-Sendable Struct

swift
class User {}

struct NonSendableStruct {
    let id = UUID()
    let user = User() // User is a class and not Sendable
}

✅ A Sendable Enum

swift
enum SendableEnum: Sendable {
    case one, two, three
    case user(SendableStruct)
}

❌ A Non-Sendable Enum

swift
enum NonSendableEnum: Sendable {
    case one, two, three
    case user(User) // User is not Sendable
}

✅ A Sendable Class

swift
final class SendableClass: Sendable {
    let id = UUID()
    let count = 0
}

❌ A Non-Sendable Class

swift
final class NonSendableClass: Sendable {
    let id = UUID()
    let user = User() // User is not Sendable
}

⚠️ Using @unchecked Sendable

There are cases where your type logically should be Sendable, but the compiler can’t verify it. In such cases, you can mark it as @unchecked Sendable manually.

This is useful during migrations and when working with legacy code, but be cautious — the compiler won’t protect you here.

🧵 Understanding @Sendable Closures

Defining and Using

swift
var myClosure: @Sendable () async throws -> Void = {
    // ...
}

func runCode(_ closure: @Sendable () -> Void) {
    // ...
}

But here's the catch:

Example:

swift
func passUserExample() async throws {
    let user = User()
    runSendableExample {
        print(user.name) // ❌ if closure is @Sendable
    }
}

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

This is technically safe, but won't compile unless you use Swift 6's sending modifier:

swift
func runSendableExample(_ closure: sending () -> Void) {
    closure()
}

📬 Swift 6 Introduces sending

In Swift 6, closures can now be marked with sending, enabling safe capture of non-Sendable values when the compiler determines it's safe.

swift
func runSendableExample(_ closure: sending () -> Void) {
    closure()
}

This allows:

swift
func passUserExample() async throws {
    let user = User()
    runSendableExample {
        print(user.name) // ✅ Compiles in Swift 6
    }
}

🧠 What's different?

• @Sendable closures: strict and isolated — only Sendable values allowed
• sending closures: compiler-analyzed and region-aware

🔒 Sending and Safety

Consider this:

swift
func passUserExample() async throws {
    let user = User()

    // First access: sending closure
    runSendableExample {
        print(user.name)
    }

    // Second access after sending
    print(user.name)
}

func runSendableExample(_ closure: sending @escaping () -> Void) {
    closure()
}

This can race, because after user is "sent" to the closure, accessing it again concurrently can lead to issues.

⚠️ Summary: Swift 5 vs Swift 6