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.
Right.
Doug