Hey all,
Swift has always been designed to be safe-by-default. This informs runtime features like bounds checking, integer overflow checking, and automatic reference counting, and type system features like optionals. But this safety has never extended to data races, which are easily created in practice and hard to completely eliminate.
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. Along the way, we need to ensure that:
- Swift 5.x and Swift 6 code can interoperate well as concurrency continues to evolve,
- Incremental adoption of the concurrency model produces incrementally better and safer code, and
- Each module, package, and program can adopt the concurrency module at its own speed without unnecessarily breaking clients.
Given the need for interoperability with existing code over years, we can restate the goal in a different way:
A program that uses the Swift 6 language mode throughout will be safe-by-default from data races.
Learning from prior transitions
Swift has been evolving for a number of years, and we’ve learned a bit about how to manage transitions. Here’s a quick summary.
- Swift 2→3: Swift 3 was a major transition for the language, and in many ways it was a painful one. First, the scope of the change was large, with a huge number of APIs changing names and many syntax changes to the language itself. Second, it was an all-or-nothing transition: with no interoperability between Swift 2 and Swift 3 code, one could not start to migrate a module until all of its dependencies had already made the switch to Swift 3. This bottom-up rewrite of the Swift ecosystem was painful and slow, effectively requiring many module authors to have two distinct versions of their code. Bottom-up rewrites like this aren’t possible given the size of the Swift ecosystem today.
- Swift 3→4→5: The syntax changes since Swift 3 has been more modest than the Swift 2→3 transformation, but more importantly, the model is different: Swift 3/4/5 code can all coexist in a program. The Swift compiler supported all of the language modes together, allowing one to mix modules compiled for the Swift 3 mode with modules compiled in Swift 4 or 5. This allowed each module to move to a newer language mode at its own pace, without breaking its clients. We also allowed features from “newer” Swift versions to be used in older language modes: for example, conditional conformances to protocols were introduced in Swift 4.1, but that compiler allowed those conformances to be written and used in the Swift 3 language mode. This allows incremental adoption of new features even before a module fully moves to a new language mode.
- Limiting @objc inference: The move from Swift 3→4 changed the rules around
@objcin a manner that broke code at runtime. To assist here, the Swift 4 compiler introduced additional compilation flags to specifically identify those parts of a Swift 3 module that would be affected by the change, with a mix of compile-time and run-time warnings. This allowed developers to slowly adapt to the change within the Swift 3 language mode before “flipping the switch” to adopt Swift 4 and the rule change. - Memory exclusivity enforcement: On the road to Swift 5, Swift tightened up rules about exclusive access to memory. For example, it became illegal to form two
inoutreferences to the same memory location at the same time. This was treated as a compiler change and was not subject to different language modes (and there’s no opt out). Instead, it was staged in over more than a year, with compiler error messages and runtime checking, so the ecosystem could adapt to the new rules.
If we take those altogether, we want to avoid anything that requires us to remake the world from the bottom up. We need to embrace individual modules moving toward the new language mode one-by-one, in any order. We should make it easy to incrementally adopt aspects of the new language model before making the jump to the new language mode, and get incremental gains from doing so. If at any point the only way forward for the developer is to switch the language mode and fix 100 errors before they can make progress, we have failed.
Concurrency in Swift 5 and 6
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:
- Certain rules to maintain the concurrency model’s guarantees will only be enforced within code that has adopted some aspect of the concurrent model (e.g., within code that is
asyncor is defined within an actor). For example, the closure passed toDispatchQueue.asyncwill be required to be@Sendableonly when called from code that has directly adopted some aspect of the concurrency model. This begins the reinterpretation of existing APIs in the manner that will be required in Swift 6. Sendableconformances can be defined and will be checked for structural correctness, butSendablerequirements will not be universally enforced, e.g., when passing a value across actors. This allowsSendableconformances to be built up throughout the ecosystem without blocking incremental adoption on a bottom-up process.- A compiler option (
-warn-concurrency) will be provided to warn about Swift 5 code that will be invalid under the Swift 6 rules. For example,Sendablewill be checked but missingSendableconformances will produce a warning (rather than an error). Developers can use this to prepare for Swift 6, by highlighting the places where fixes will be needed, but without needing to fully adopt Swift 6. The behavior of this flag will evolve as we narrow in on the semantics of Swift 6. - A compiler option (
-enable-actor-data-race-checks) will be provided to diagnose any runtime data races caused by missed checks in Swift 5. For example, if Swift 5 code executes a non-@Sendableclosure concurrently, this flag will detect at runtime that a synchronous actor-isolated function was called on the wrong executor.
Swift 6 will not be available as part of the initial release of Swift Concurrency. Instead, the initial release of Swift Concurrency provides the fundamental tools for concurrent programming in the manner that will help eliminate many data races. Swift 5 will then continue to provide source compatibility with prior versions of Swift, allowing developers to incrementally adopt the new concurrency features. Feedback from the use of the concurrency features in Swift 5 will direct further refinements and improvements to the concurrency model, so that Swift 6 can deliver on its promise to be safe-by-default from data races.
Staging tools for Swift 5 and 6
The Swift compiler can manage the Swift 5 and 6 language modes, making specific diagnostics silent/warning/error as appropriate. However, to facilitate a smooth transition, we need to be able to distinguish between APIs that have always used the concurrency features (and therefore should always follow the safety rules) vs. those that existed prior to the introduction to concurrency yet need to work safely with it. For example, consider the DispatchQueue.async method mentioned earlier. It looks something like this today:
// Existing, Swift 5 definition
extension DispatchQueue {
func async(execute work: @escaping () -> Void)
}
In Swift 6, we need its closure parameter to be @Sendable :
// Correct Swift 6 definition
extension DispatchQueue {
func async(execute work: @Sendable @escaping () -> Void)
}
There are a few options for dealing with this:
- Deprecate or remove the API in Swift 6, which will potentially cause excess code churn
- Change the API in Swift 6 and have Swift 5 ignore
@Sendableclosure requirements, which would make Swift 5 code using concurrency less safe than it could be (e.g., we’d allow actor-isolated closures to be passed to this function) - Annotate the API to state that it used to be non-
@Sendablebut should be@Sendablein Swift 6.
The Swift compiler has a few hidden attributes to implement the last of these options. We’ll likely need to augment or replace these attributes with a more holistic scheme. For this API, we use the parameter attribute @_unsafeSendable :
extension DispatchQueue {
func async(@_unsafeSendable execute work: @escaping () -> Void)
}
The @_unsafeSendable parameter attribute says that the parameter’s type will be treated as @Sendable in Swift 6 and within a context in Swift 5 code that has adopted concurrency, but will be non- @Sendable everywhere else. Unlike @Sendable , it also has no ABI impact, so an existing API can be augmented with this attribute without breaking either source compatibility or ABI for existing code.
Similarly, declarations can be marked with the “unsafe” form of a global actor, meaning that they should be considered to be a part of the global actor, but that should only be enforced in Swift 6 code or Swift 5 code that has adopted concurrency. For example:
@MainActor(unsafe) func renderUI() { ... }
This function will be treated as @MainActor when in code that has adopted concurrency or is compiled in Swift 6 mode, and unspecified elsewhere. In practice, this affects the type of the function:
let fn1 = renderUI // type is () -> Void in Swift 5, @MainActor () -> Void in Swift 6
func newCode() async {
let fn2 = renderUI // type is @MainActor () -> Void everywhere
}
Global actors and @Sendable are the places where we have found that we needed the “unsafe” attribute variants to allow for evolving Swift toward Swift 6. There are likely more such places, and we’ll want to develop an overall approach that developers can understand and embrace to make for a smooth migration from Swift 5 to Swift 6, providing incremental benefits for incremental adoption of concurrency features.
Doug