Problematic Swift Concurrency Patterns
I think the vast majority of the time, a global actor should be applied to the type as a whole, not to individual properties.
[…]
But, while
detacheddoes prevent isolation inheritance, it also does other stuff too. Detached tasks do not inherit priority or task-local values. Instead, think about anonisolatedfunction.[…]
I think
MainActor.runis rarely the right solution.[…]
Moving from completion handlers to async methods can change semantics and cause code to run on background threads. Be really careful here!
[…]
The compiler will automatically generate async versions of Objective-C completion handler-based methods. The bad news is, unless the type itself is
MainActor-isolated orSendable, these translations will be problematic. They won’t be possible to use diagnostic-free without a@preconcurrency importand will have different semantics that could make them unsafe.
Previously:
- Swift Concurrency and Objective-C
- Unwanted Swift Concurrency Checking
- Swift 6
- The Bleeding Edge of Swift Concurrency
1 Comment RSS · Twitter · Mastodon
I appreciate Matt's writeups and being a forerunner on this stuff. He's been very helpful.
Everything I read here is a mess. This is exactly what I don't want to deal with. I can't wrap my head around a lot of it.
I'm going to stick with GCD + queues or locks and non-Swift langs. The patterns and pitfalls are well-understood. Keep it simple.
