Concurrency in Swift 5 and 6: Data Races
An explicit goal of the concurrency effort for Swift 6 is to make safe-by-default also extend to data races. The type system and language model work together, through features like actors,
Sendable, and global actors, to eliminate data races.However, there is a lot of Swift code out there that was developed without the Swift concurrency model. Some portion of that code is going to have to change to fit within the constraints of Swift’s concurrency model, but it’s not going to be rewritten in a month or even a year. We need to consider what it’s going to look like to migrate the Swift ecosystem to Swift 6, and expect that this process will take years.
[…]
To enable the incremental rollout of Swift 6’s safe-by-default for data races, we’ll allow the use of concurrency features in Swift 5 with a “relaxed” enforcement model that allows incremental adoption[…]
See also: Swift by Sundell.
Previously:
- Swift Proposal: Actors
- Swift Proposal: ConcurrentValue and @concurrent Closures
- Swift Concurrency Roadmap
- Swift 5 Exclusivity Enforcement
7 Comments RSS · Twitter
All very nice, but dealing with concurrency is never or a minor issue I have with my code.
Major issues I struggle daily with are slow compile times, compiler crashes, compiler bugs, a non working debugger, death-by-generics, ever increasing complexity.
I wish Apple would fix those: that would really boost my productivity. Async/await doesn’t improve my productivity.
Since Swift, everything is about code architecture instead of creating delightful products and UX
>All very nice, but dealing with concurrency is never or a minor issue I have with my code.
Are you sure about that? In my apps, a scenario like "I want to fetch some data from an API / save my memory cache to a file / etc., and in the meantime the CPU is largely idling, so it'd be nice if doing so didn't block the UI" is extremely common.
@Sören Of course, but that has been a solved problem for at least 10+ years now. Nothing async/await gives me allows will enhance my productivity, while having a functional debugger, a faster compiler and no more crashes would tremendously boost the performance of my team.
@A It’s a solved problem if you never write bugs, but the idea is that putting this in the language and type system will help prevent certain classes of bugs, and I believe there are performance benefits as well (not to mention code readability). That said, I agree that the other tooling improvements are also needed.
> Of course, but that has been a solved problem for at least 10+ years now.
I don't think it's an accident that many languages are moving to the F#-pioneered approach of async/await.
Yes, concurrency in principle has been well-understood for a long time. But in practice, writing concurrent code is often obnoxious enough to write (with, e.g. callbacks) that you avoid doing so altogether. Or you do write it, but no longer have a good understanding of what your code does, leading to poor maintainability.
async/await simplifies that. (Which, of course, comes with its own warts, cf. leaky abstractions).
> Nothing async/await gives me allows will enhance my productivity
I think you'll find that it will!
> having a functional debugger, a faster compiler and no more crashes would tremendously boost the performance of my team
Absolutely, but the Swift team doesn't seem to be standing still on those. 5.4 has "Build Performance" as a headline feature, 5.3 had "Build Time Improvements", and so on. They don't seem satisfied with the status quo.
And I do think, frankly, that good language support for concurrency was verging on overdue.
"Absolutely, but the Swift team doesn't seem to be standing still on those."
I'm following a lot of Swift compiler bugs, and I haven't seen any progress on them in the past year. They're putting a lot of effort into performance. I wish they'd put some of that effort into not crashing.
Apple is infamous for their culture of only fixing new bugs. It's exceptionally rare that I see them fix a bug that's been around for a year or more.
@Ted I think my top Swift bug is that sometimes you get spurious compiler errors (which first are confusing and take you out of flow) that go away when you do a clean build (which takes a long time).
