# Design Priorities for the Swift 6 Language Mode

**URL:** <https://forums.swift.org/t/design-priorities-for-the-swift-6-language-mode/62408>\
**Category:** Announcements\
**Created:** [January 5, 2023, 4:51pm UTC](https://forums.swift.org/t/design-priorities-for-the-swift-6-language-mode/62408 "2023-01-05T16:51:46Z")\
**Posts on this page:** 1\
**Showing post:** 57

<div class="post-metadata">

**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:** [January 18, 2023, 7:56pm UTC](https://forums.swift.org/t/design-priorities-for-the-swift-6-language-mode/62408/57 "2023-01-18T19:56:36Z")

</div>

> [@jeremyabannister](#):
>
> Is the idea that even though technically we can introduce breaking changes in a major version update, there's still a strong pressure to keep those breakages minimal, and that in the case of Swift 6 the bar is that the breakage must directly solve a problem, and not just be for the purpose of compiler hygiene, for example?

Perhaps I can provide more motivation here, but speaking more for myself than for the language workgroup as a whole. The strong pressure to keep incompatibilities minimal comes from a desire to ensure that the Swift ecosystem can reasonably move forward to Swift 6. Swift 6 can't be so different from Swift 5 that the code is not recognizable as being the same language, or it requires so much effort to adopt that few people do. The programming-languages landscape is rife with cautionary tales, including our own:

- Swift 2 -\> 3 was really rough. The feel of the language changed significantly, existing tutorials and blog posts got invalidated, and you needed to migrate an entire program at once. That was more than 6 years ago and the pain still lingers.
- Perl 5 -\> 6 just didn't happen. Perl 6 started more than 20 years ago, and got renamed to Raku when it was clear that "Perl 6" was so different that there wasn't an evolutionary path.
- Python 2 -\> 3 has been more than a decade in the making, with users often having dual Python installations and lots of developer pain as folks to try write their code so it works with both.
- Scala 2 -\> 3 is still unfolding (it's been less than 2 years since Scala 3 was released), but it's clear that many folks are hanging back on Scala 2 for now, and both Scala 2.x and 3.x are supported with different toolchains.

There are languages like C and C++ that very rarely change or remove anything in a source-incompatible way. The priorities outlined by the language workgroup already imply more than that level of change, so I don't think there's a useful comparison there.

> [@John\_McCall](#):
>
> I would just add to that that these language changes do not generally remove complexity from the compiler, because the same compiler has to continue to support old language versions. They can _speed up_ the compiler, if they allow it to apply rules that are easier to check, but they don’t _simplify_ it.

Right.

Doug

---

_[View the full topic](https://forums.swift.org/t/design-priorities-for-the-swift-6-language-mode/62408)._