# Progress toward the Swift 6 language mode **URL:** \ **Category:** Announcements\ **Created:** [November 7, 2023, 6:06pm UTC](https://forums.swift.org/t/progress-toward-the-swift-6-language-mode/68315 "2023-11-07T18:06:42Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![hborla](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/hborla/32/27563_2.png) [@hborla](https://forums.swift.org/u/hborla)\ **Post date:** [November 7, 2023, 6:06pm UTC](https://forums.swift.org/t/progress-toward-the-swift-6-language-mode/68315/1 "2023-11-07T18:06:42Z")
Since the last update laying out the [design priorities for the Swift 6 language mode](https://forums.swift.org/t/design-priorities-for-the-swift-6-language-mode/62408), the project has been making steady advances towards this next milestone. However, some of the previously stated goals include open-ended research questions that are still in the early stages of development. Instead of holding up Swift 6 as this work progresses, the Language Steering Group is **narrowing the focus of remaining changes for Swift 6 to data-race safety by default**. ## Readiness of data-race safety by default There are still a number of bugs and holes in the Sendable checking model that admit data races under strict concurrency checking. Equally important, strict concurrency checking currently issues a significant number of false positive reports of data races, making the complete checking difficult to program against. **The Swift 6 language mode will only be declared ready once the Language Steering Group determines that the programming model is effective and usable.** The remaining language work to complete data-race safety for the Swift 6 language mode will fall into two categories: 1. Fill all holes in the strict concurrency model so that data races are diagnosed statically, or dynamically where static safety cannot be proven. 2. Mitigate false reports of data races on patterns that are proven to be safe. Swift 5.10 contains a number of significant bug fixes in the actor isolation and Sendable checking. In addition, the following language changes are currently being designed and implemented to undergo the Swift evolution review process: - [SE-0411: Isolated default value expressions](https://forums.swift.org/t/se-0411-isolated-default-value-expressions/68065) - [Inferring `@Sendable` for methods and key-path literals](https://forums.swift.org/t/pitch-inferring-sendable-for-methods-and-key-path-literals/68011) - [Strict concurrency checking for global and static variables](https://forums.swift.org/t/pitch-strict-concurrency-for-global-variables/66908) - [Improved control over closure actor isolation](https://github.com/apple/swift-evolution/blob/3644f682913c8d0b2eafb1945ff81105fbdc7783/proposals/NNNN-improved-control-over-closure-actor-isolation.md) - [Lifting restrictions on non-`Sendable` values through isolated value regions](https://forums.swift.org/t/pitch-region-based-isolation/67888) Together, these changes fill the remaining major holes in strict concurrency checking and improve the usability of strict concurrency checking by introducing more `Sendable` inference and enabling safe ways to transfer non-`Sendable` values across isolation boundaries. The Language Steering Group acknowledges that other language changes in the area of concurrency are important, but the changes above are necessary for defining the Swift 6 language mode. Other concurrency features are additive and can be explored independently. ## The Swift 6 migration [Upcoming features](https://github.com/apple/swift-evolution/blob/main/proposals/0362-piecemeal-future-features.md) are critical for migrating to the Swift 6 language mode: one can enable individual upcoming features one at a time to incrementally move a code base toward Swift 6, before adopting the full language mode. There are a number of previously-accepted upcoming features that will be enabled by default in Swift 6: - SE-0274: [Concise magic file names](https://github.com/apple/swift-evolution/blob/main/proposals/0274-magic-file.md#concise-magic-file-names) (`ConciseMagicFile`) - SE-0286: [Forward-scan matching for trailing closures](https://github.com/apple/swift-evolution/blob/main/proposals/0286-forward-scan-trailing-closures.md#forward-scan-matching-for-trailing-closures) (`ForwardTrailingClosures`) - SE-0337: [Incremental migration to concurrency checking](https://github.com/apple/swift-evolution/blob/main/proposals/0337-support-incremental-migration-to-concurrency-checking.md) (`StrictConcurrency`) - SE-0354: [Regex Literals](https://github.com/apple/swift-evolution/blob/main/proposals/0354-regex-literals.md#regex-literals) (`BareSlashRegexLiterals`) - SE-0383: [Deprecate @UIApplicationMain and @NSApplicationMain](https://github.com/apple/swift-evolution/blob/main/proposals/0383-deprecate-uiapplicationmain-and-nsapplicationmain.md) (`DeprecateApplicationMain`) - SE-0384: [Importing Forward Declared Objective-C Interfaces and Protocols](https://github.com/apple/swift-evolution/blob/main/proposals/0384-importing-forward-declared-objc-interfaces-and-protocols.md#importing-forward-declared-objective-c-interfaces-and-protocols) (`ImportObjcForwardDeclarations`) - SE-0401: [Remove Actor Isolation Inference caused by Property Wrappers](https://github.com/apple/swift-evolution/blob/main/proposals/0401-remove-property-wrapper-isolation.md#remove-actor-isolation-inference-caused-by-property-wrappers) (`DisableOutwardActorInference`) - SE-0409: [Access-level modifiers on import declarations](https://github.com/apple/swift-evolution/blob/main/proposals/0409-access-level-on-imports.md) (`InternalImportsByDefault`) The Language Steering Group has decided that one previously-accepted upcoming feature, `ExistentialAny`, will **not** be enabled by default in Swift 6. [SE-0335: Introduce existential `any`](https://github.com/apple/swift-evolution/blob/main/proposals/0335-existential-any.md) introduces the `any` keyword to identify existential types. The proposal also specifies that "bare" protocol names will no longer be permitted as types---they must either use `any` or `some`, as appropriate---under the upcoming feature flag `ExistentialAny`. Given the concerns about migration to consistent use of existential `any` in the language, and the expectation that additional language improvements will be coming that might affect the end result of that migration, the Language Steering Group is deferring the source-incompatible changes in SE-0335 to a future language revision. Additional evolution proposals may include source-incompatible changes for Swift 6, and the Language Steering Group will evaluate such proposals on a case-by-case basis for high value to the language relative to the cost of source incompatibilities. For example, sufficiently high value changes might include minor type inference changes that are necessary for completing a major feature, such as typed throws, or semantic changes in pursuit of data race safety. Once all of the upcoming features for Swift 6 are in place, the Language Steering Group will provide a migration guide that suggests an optimal path for incrementally enabling strict concurrency checking in a project, along with practical guidance on how to address certain kinds of strict concurrency violations in common code patterns. Community feedback on these guides will be critical to evaluating the approachability of the Swift 6 migration. ---
**Author:** ![FranzBusch](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/franzbusch/32/19447_2.png) [@FranzBusch](https://forums.swift.org/u/FranzBusch)\ **Post date:** [November 7, 2023, 7:19pm UTC](https://forums.swift.org/t/progress-toward-the-swift-6-language-mode/68315/2 "2023-11-07T19:19:02Z")
Great to see all of the work on fixing `Sendable` holes and making it easier to use. We have seen a lot of new warnings in our Swift on Server repositories and those have uncovered real data races! Can't wait to see how region based isolation is going to make even more safe patterns compile-time safe. One thing that came up again in our recent Swift on Server workgroup meeting w.r.t. Swift 6 is the long standing issue of non-extensible enums for libraries in non-library-evolution mode. This has caused significant pain over the past years and continues to be a sharp edge for developers which often lead to accidental API breaks. Furthermore, with the introduction of `swift-foundation` this becomes more important since `swift-foundation` ships a number of non-frozen enums which behave differently in the two modes. I know this is an update post but I just wanted to voice our recent discussions in the SSWG here again. ---
**Author:** ![Karl](https://avatars.discourse-cdn.com/v4/letter/k/34f0e0/32.png) [@Karl](https://forums.swift.org/u/Karl)\ **Post date:** [November 7, 2023, 7:29pm UTC](https://forums.swift.org/t/progress-toward-the-swift-6-language-mode/68315/3 "2023-11-07T19:29:18Z")
> [@FranzBusch](#): > > One thing that came up again in our recent Swift on Server workgroup meeting w.r.t. Swift 6 is the long standing issue of non-extensible enums for libraries in non-library-evolution mode. I was actually working on that recently when I uncovered [this hole](https://forums.swift.org/t/design-priorities-for-the-swift-6-language-mode/62408/81), which I also hope can be patched in Swift 6. That said, I think non-frozen enums are an additive change. I highly doubt we are going to change the default behaviour of enums, so you're going to have to opt-in to extensibility via some kind of `@nonfrozen` attribute (although now we have a notion of cross-module-but-same-package in the compiler, there would likely be less breakage than previously expected). ---
**Author:** ![xwu](https://avatars.discourse-cdn.com/v4/letter/x/b487fb/32.png) [@xwu](https://forums.swift.org/u/xwu)\ **Post date:** [November 7, 2023, 7:56pm UTC](https://forums.swift.org/t/progress-toward-the-swift-6-language-mode/68315/4 "2023-11-07T19:56:46Z")
> [@Karl](#): > > I was actually working on that recently when I uncovered [this hole](https://forums.swift.org/t/design-priorities-for-the-swift-6-language-mode/62408/81), which I also hope can be patched in Swift 6. The language steering group discussed this issue also, and an announcement on it will follow shortly. ---
**Author:** ![asdf](https://avatars.discourse-cdn.com/v4/letter/a/ebca7d/32.png) [@asdf](https://forums.swift.org/u/asdf)\ **Post date:** [November 7, 2023, 8:10pm UTC](https://forums.swift.org/t/progress-toward-the-swift-6-language-mode/68315/5 "2023-11-07T20:10:35Z")
what about [Noncopyable Generics](https://forums.swift.org/t/pitch-noncopyable-generics/68180) ? ---
**Author:** ![John\_McCall](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/john_mccall/32/1351_2.png) [@John\_McCall](https://forums.swift.org/u/John_McCall)\ **Post date:** [November 7, 2023, 9:22pm UTC](https://forums.swift.org/t/progress-toward-the-swift-6-language-mode/68315/6 "2023-11-07T21:22:38Z")
We don't expect generics for non-copyable types to change the rules for existing code, so it won't be limited to a specific language mode. ---
**Author:** ![wes1](https://avatars.discourse-cdn.com/v4/letter/w/848f3c/32.png) [@wes1](https://forums.swift.org/u/wes1)\ **Post date:** [November 7, 2023, 9:39pm UTC](https://forums.swift.org/t/progress-toward-the-swift-6-language-mode/68315/7 "2023-11-07T21:39:30Z")
Great: Swift 6 looks doable and valuable! (Edit: removed as presumably off-topic) ---
**Author:** ![8675309](https://avatars.discourse-cdn.com/v4/letter/8/ea5d25/32.png) [@8675309](https://forums.swift.org/u/8675309)\ **Post date:** [November 8, 2023, 3:53pm UTC](https://forums.swift.org/t/progress-toward-the-swift-6-language-mode/68315/8 "2023-11-08T15:53:39Z")
It's been several years talking about Swift 6 and breaking changes. Is there a plan to release a language breaking version every few years? Any plans to have an ABI-breaking version one day to be able to address some of the language warts and design choices that would be nice to rethink? ---
**Author:** ![Max\_Desiatov](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/max_desiatov/32/20654_2.png) [@Max\_Desiatov](https://forums.swift.org/u/Max_Desiatov)\ **Post date:** [November 8, 2023, 4:25pm UTC](https://forums.swift.org/t/progress-toward-the-swift-6-language-mode/68315/9 "2023-11-08T16:25:33Z")
> [@8675309](#): > > Any plans to have an ABI-breaking version one day to be able to address some of the language warts and design choices that would be nice to rethink? Swift is ABI-stable only on Darwin platforms. An ABI break there would break system libraries that are written in Swift, and apps that use them as a consequence. ---
**Author:** ![John\_McCall](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/john_mccall/32/1351_2.png) [@John\_McCall](https://forums.swift.org/u/John_McCall)\ **Post date:** [November 8, 2023, 4:57pm UTC](https://forums.swift.org/t/progress-toward-the-swift-6-language-mode/68315/10 "2023-11-08T16:57:57Z")
> [@8675309](#): > > It's been several years talking about Swift 6 and breaking changes. Is there a plan to release a language breaking version every few years? There is no specific plan to have a regular cadence of new language modes. As time goes on, the burden for major breaks increases, and we’ll need strong justifications for them. Most of the breaks in Swift 6 are very minor; the exceptions are all in service of concurrency safety, which is a major goal for the language. The Language Steering Group is already looking at what might justify major breaks for a hypothetical Swift 7, if anything. Right now, the main thing that would qualify to me would be changes that would rein in the exponential expectations on the type-checker. Getting that right without being _too_ disruptive could be quite a long project, though. ---
**Author:** ![itaiferber](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/itaiferber/32/33840_2.png) [@itaiferber](https://forums.swift.org/u/itaiferber)\ **Post date:** [November 8, 2023, 5:16pm UTC](https://forums.swift.org/t/progress-toward-the-swift-6-language-mode/68315/11 "2023-11-08T17:16:02Z")
> [@Max\_Desiatov](#): > > An ABI break there would break system libraries that are written in Swift, and apps that use them as a consequence. To put this more strongly: on platforms which promise ABI stability, **no** ABI breakage is considered acceptable due to risk to end users of those platforms. Source breakages can be considered with language modes because they require recompilation in order take effect, and affect only developers; ABI breakages lead to existing binaries no longer behaving as expected (usually by crashing, but sometimes by silently corrupting data). ---
**Author:** ![wadetregaskis](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/wadetregaskis/32/8494_2.png) [@wadetregaskis](https://forums.swift.org/u/wadetregaskis)\ **Post date:** [November 8, 2023, 5:24pm UTC](https://forums.swift.org/t/progress-toward-the-swift-6-language-mode/68315/12 "2023-11-08T17:24:31Z")
> [@itaiferber](#): > > ABI breakages lead to existing binaries no longer behaving as expected (usually by crashing, but sometimes by silently corrupting data). Is that inevitable, though? I don't know the details of how Swift implements its ABI and library versioning, but in other languages & packaging systems (e.g. Objective-C frameworks) there are specific mechanisms for supporting multiple ABIs (e.g. look in any framework and see that it contains a _Versions_ folder, usually with just an _A_ subfolder, but you can in fact have _B_, _C_, etc and link against specific versions). The "we can never change the ABI" doesn't really seem viable, any more than it would be to say "we can never remove any API or framework". Imagine if every framework and API therein, that Apple has _ever_ shipped since MacOS X Developer Preview 1, had to still be in macOS Sonoma (_and_ still fully functional, lest that lead to applications crashing or corrupting data). ---
**Author:** ![itaiferber](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/itaiferber/32/33840_2.png) [@itaiferber](https://forums.swift.org/u/itaiferber)\ **Post date:** [November 8, 2023, 5:54pm UTC](https://forums.swift.org/t/progress-toward-the-swift-6-language-mode/68315/13 "2023-11-08T17:54:03Z")
> [@wadetregaskis](#): > > The "we can never change the ABI" doesn't really seem viable, any more than it would be to say "we can never remove any API or framework". Imagine if every framework and API therein, that Apple has _ever_ shipped since MacOS X Developer Preview 1, had to still be in macOS Sonoma (_and_ still fully functional, lest that lead to applications crashing or corrupting data). Except in extenuating circumstances, this _is_ actually how system frameworks on Darwin platforms typically work: code is overwhelmingly only deprecated, not removed. Certain frameworks _have_ been phased out over time (e.g., Carbon), but over the span of decades and not years, after the vast majority of clients have already migrated off. APIs are basically only removed either by accident, or when the entire framework goes away after an extremely long deprecation period (if ever). Foundation, for example, _does_ contain code that spans all the way back to its introduction (... and earlier), even though you'd never use those APIs today (and new usage is **highly** discouraged) — see, e.g., `NSConnection` and the Distributed Object APIs. > [@wadetregaskis](#): > > in other languages & packaging systems (e.g. Objective-C frameworks) there are specific mechanisms for supporting multiple ABIs Support for multiple ABIs would be _excellent_, though it's not an ABI _breakage_. If we did want to make ABI changes, this would necessarily be the path forward; it's just not something that, to my knowledge, Swift supports today. (Some languages [**cough** C++ **cough**], by the way, _have_ in the past decided to simply break ABI and say "tough luck" to all existing clients and binaries... But that's just not an acceptable position for frameworks that ship with the system.) ---
**Author:** ![jrose](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jrose/32/408_2.png) [@jrose](https://forums.swift.org/u/jrose)\ **Post date:** [November 8, 2023, 6:27pm UTC](https://forums.swift.org/t/progress-toward-the-swift-6-language-mode/68315/14 "2023-11-08T18:27:05Z")
I’ll note the B, C, etc subsystem is basically considered dead because it _forks the entire downstream module graph._ It’s like introducing a new platform architecture, but without actually having a new architecture: everything downstream needs to be recompiled to work together, and you have to maintain two variations and have twice the code on disk until the old architecture goes away. (Which, by the way, is the most likely opportunity for ABI improvements on Apple platforms, if they ever switch to aarch128 or riscX or whatever. But that’s probably a long way off, and not under the Swift community’s control, and still doesn’t remove the old architecture for many years after that.) ---
**Author:** ![jeremy](https://avatars.discourse-cdn.com/v4/letter/j/82dd89/32.png) [@jeremy](https://forums.swift.org/u/jeremy)\ **Post date:** [November 8, 2023, 7:04pm UTC](https://forums.swift.org/t/progress-toward-the-swift-6-language-mode/68315/15 "2023-11-08T19:04:30Z")
> [@itaiferber](#): > > Certain frameworks _have_ been phased out over time (e.g., Carbon) Carbon was removed during the transition from 32-bit to 64-bit. OpenTransport was removed some time before that. Also: QuickDraw GX in pre-OSX days. If frameworks are being removed less frequently, that's a good thing for application developers. Some of these changes were very disruptive. ---
**Author:** ![wadetregaskis](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/wadetregaskis/32/8494_2.png) [@wadetregaskis](https://forums.swift.org/u/wadetregaskis)\ **Post date:** [November 8, 2023, 7:17pm UTC](https://forums.swift.org/t/progress-toward-the-swift-6-language-mode/68315/16 "2023-11-08T19:17:45Z")
> [@jrose](#): > > I’ll note the B, C, etc subsystem is basically considered dead because it _forks the entire downstream module graph._ It’s like introducing a new platform architecture, but without actually having a new architecture: everything downstream needs to be recompiled to work together, and you have to maintain two variations and have twice the code on disk until the old architecture goes away. Yep, it has a cost. It's not something that Apple has ever done for public frameworks, that I'm aware of. But I believe it was done for private frameworks (I specifically recall dealing with this for a private framework when I was at Apple, eons ago). There's also clearly technical avenues for ameliorating that, such as only installing the "old" versions of frameworks on-demand. > [@jrose](#): > > Which, by the way, is the most likely opportunity for ABI improvements on Apple platforms, if they ever switch to aarch128 or riscX or whatever. But that’s probably a long way off… Exactly. There's _nothing_ in the foreseeable future that's going to be a convenient excuse to clean house. That's why I think it's worth looking at other options. Also, keep in mind that Apple _does_ quite often break applications, sometimes in pretty serious ways, between OS releases. Not through relatively clean methods like removing frameworks or breaking ABIs, but by silently changing the runtime behaviour of frameworks. Sometimes they even do that knowingly and deliberately, in apparent ignorance or disregard of its impact on developers and end-users. So I think the "Apple can't break ABI because it would be unprecedented" [aspect of the] excuse is functionally false. ---
**Author:** ![Douglas\_Gregor](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/douglas_gregor/32/1362_2.png) [@Douglas\_Gregor](https://forums.swift.org/u/Douglas_Gregor)\ **Post date:** [November 8, 2023, 7:20pm UTC](https://forums.swift.org/t/progress-toward-the-swift-6-language-mode/68315/17 "2023-11-08T19:20:11Z")
> [@wadetregaskis](#): > > Is that inevitable, though? I don't know the details of how Swift implements its ABI and library versioning, but in other languages & packaging systems (e.g. Objective-C frameworks) there are specific mechanisms for supporting multiple ABIs (e.g. look in any framework and see that it contains a _Versions_ folder, usually with just an _A_ subfolder, but you can in fact have _B_, _C_, etc and link against specific versions). As others have noted, the `Versions` folder approach is a dead-end. Note that it only exists in the macOS SDK (where there is only ever a single version, usually `A`) and none of the Apple SDKs for newer platforms (iOS, watchOS, etc.) have it. As for how Swift approaches ABI stability, I gave a [talk on the subject](https://www.youtube.com/watch?v=MgPBetJWkmc) last year that goes into the goals and technical details. We're really far afield now from the original topic of this point. The answer to the original question is: it is unlikely that there will ever be ABI-breaking changes to Swift, at least not in the foreseeable future, but with enough effort we can stage in most anything we need in ABI-compatible ways. Doug ---
**Author:** ![itaiferber](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/itaiferber/32/33840_2.png) [@itaiferber](https://forums.swift.org/u/itaiferber)\ **Post date:** [November 8, 2023, 8:05pm UTC](https://forums.swift.org/t/progress-toward-the-swift-6-language-mode/68315/18 "2023-11-08T20:05:38Z")
> [@jeremy](#): > > Carbon was removed during the transition from 32-bit to 64-bit. > **Aside** > > For the curious, Carbon deprecation effectively began in 2007 with the Intel transition (Carbon was intentionally never ported to 64-bit), and over time, various APIs were more explicitly deprecated. IIRC, updates to Carbon APIs stopped coming around the Mountain Lion timeframe, the final removal only came when 32-bit support was dropped altogether — I _believe_ announced in with High Sierra, but only happened with Catalina? So, quite a lifecycle... ---
**Author:** ![taylorswift](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/taylorswift/32/43413_2.png) [@taylorswift](https://forums.swift.org/u/taylorswift)\ **Post date:** [November 8, 2023, 10:06pm UTC](https://forums.swift.org/t/progress-toward-the-swift-6-language-mode/68315/19 "2023-11-08T22:06:52Z")
> [@John\_McCall](#): > > There is no specific plan to have a regular cadence of new language modes. As time goes on, the burden for major breaks increases, and we’ll need strong justifications for them. Most of the breaks in Swift 6 are very minor; the exceptions are all in service of concurrency safety, which is a major goal for the language. > > The Language Steering Group is already looking at what might justify major breaks for a hypothetical Swift 7, if anything. Right now, the main thing that would qualify to me would be changes that would rein in the exponential expectations on the type-checker. Getting that right without being _too_ disruptive could be quite a long project, though. what would it take to solve [CommandLine.arguments and CommandLine.argc should be deprecated and replaced with immutable equivalents. · Issue #66213 · apple/swift · GitHub](https://github.com/apple/swift/issues/66213) ? ---
**Author:** ![Nobody1707](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/nobody1707/32/2169_2.png) [@Nobody1707](https://forums.swift.org/u/Nobody1707)\ **Post date:** [November 8, 2023, 10:43pm UTC](https://forums.swift.org/t/progress-toward-the-swift-6-language-mode/68315/20 "2023-11-08T22:43:30Z")
I seem to remember that Carbon was ported to 64-bit PowerPC, and that an x86-64 port of Carbon was announced (and might have even been available in a beta release of OS X) then canceled shortly after. But that was just the UI layer of Carbon, I believe a few bits of the non-UI parts of Carbon might still exist on MacOS even today. [Next page](https://forums.swift.org/t/progress-toward-the-swift-6-language-mode/68315.md?page=2)