Keeping the default language mode at -swift-version 5
is the only choice that doesn't compromise source compatibility. There is too much code out there that doesn't specify any language version, which means it's building with -swift-version 5
. That code cannot break just by upgrading to Swift 6.0 tools. I believe the fact that the Swift 5.0 compiler changed the default language mode is part of the reason why much of the community has been worried about the Swift 6.0 compiler breaking their code without them having done anything to opt into complete concurrency checking. The Swift 6 migration is more involved than previous migrations, and it will not be forced on anybody who does not want to migrate.
It depends on what is meant by "Swift 6 features". You will need to pass -swift-version 6
to enable the source-incompatible upcoming features that are enabled by default in the Swift 6 language mode, which is primarily complete concurrency checking. Other features, like typed throws, can be used without passing -swift-version 6
.
I think there are other ways to encourage code to be written in the Swift 6 language mode as the Swift ecosystem grows, such as changing any templates, e.g. the package template created with swift package init
, to explicitly specify -swift-version 6
from the start. I think the best path for getting the community to migrate to Swift 6 is for them to want to migrate, not for them to download a new tool set and have their existing code break, leading them to believe they need to fix the errors instead of fixing their build setup to explicitly specify -swift-version 5
.
It might be possible to move to a world where all code using prior language versions has to explicitly specify it. For that, we would probably need some kind of file-level directive for specifying language versions in a primary file, e.g. main.swift
.