Mastodawn

Swift concurrency nOOb question: if you're using Approachable Concurrency and you get warnings about using Sendable structs in non-main-actor contexts, is the recommended workaround to mark them as nonisolated?

Also, it seems odd to me that marking a struct as Sendable doesn't already exempt it from default MainActor isolation. Is there a good reason why you'd want to limit Sendable types to MainActor?

Show thread

Alex Ozun Feb 2

@nicklockwood Sendability and Isolation are orthogonal concepts. Your structs are still MainActor-isolated, and just because they are Sendable doesn't mean you can access them outside MainActor. In fact, they are automatically Sendable precisely because you can only access them serially on MainActor.
For global-actor-isolated types Sendable is guaranteed by accessing on a serial queue.
For nonisolated types, Sendable is guaranteed by immutability or by internal synchronisation.

Show thread

Nick Lockwood Feb 2

@alexozun sure, I understand that. But I'm talking about structs that are explicitly marked as Sendable and that the compiler has already approved as being conformant to Sendability requirements (regardless of the compiler-level concurrency defaults)

IUUC, conforming a type to Sendable means saying that it's safe to access from multiple actors concurrently, so why would you ever want a type that is marked as Sendable to also be MainActor-isolated?

Show thread

Alex Ozun

@nicklockwood > "Sendable means saying that it's safe to access from multiple actors concurrently"
Nitpick: access from multiple isolation contexts, not actors. If your data is isolated to MainActor you can only access it on this actor. Sendable just allows you to safely pass this data between isolation boundaries, but in the end you're still forced to access it on MainActor.
Sendable+nonisolated: cross boundaries and access directly.
Sendable+MainActor: cross boundaries and access on MainActor.

Show thread

Ivan Cantarino Feb 2

@alexozun @nicklockwood this sums it up, great explanation 🙌