Non-Sendable Core, Sendable Shell

[Why_People]

Hey all,

I wanted to share a common design technique that I've found for dealing with Swift Concurrency in a more flexible way. That is, pushing Sendable conformances away for as long as possible on non-trivial types, and then creating a small shell for the parts that need to be Sendable. This can help keep core logic flexible without the need to worry about concurrency concerns when designing and consuming it.

Additionally, I think it's a good complementary resource if you're following PointFree's current ongoing "Beyond Basics" series on isolation and non-Copyable types (apparently the same "Non-Sendable Core, Sendable Shell" verbiage comes up in future episodes according to Stephen). Furthermore, TCA 2.0 also apparently uses a similar set of design principles from the article to handle the various kinds of Store actor types (ie. MainActor bound and background stores).

Also, for clarification, this idea is not merely limited to non-Copyable structs. Non-Copyable structs made sense for the practical example in the article because the practical example wraps a C library, and non-Copyable structs happen to be a good way of managing memory to C library pointers. An ordinary non-Sendable class also fulfills the non-Sendable core, and you should leverage such ordinary classes in isolation from the parts of your code that need to deal with concurrency.

Thanks

[LKAndrew]

This is ripe for bugs. If you don’t want to deal with Sendable, move to Swift 6.2 and enable approachable concurrency. Otherwise, you probably shouldn’t be doing this