Reviews are an important part of the Swift evolution process. All review feedback should be either on this forum thread or, if you would like to keep your feedback private, directly to me as the review manager, either via email or the forum messaging feature. When contacting me directly, please put "SE-0441" somewhere near the start of the subject line.
What goes into a review?
The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:
What is your evaluation of the proposal?
Is the problem being addressed significant enough to warrant a change to Swift?
Does this proposal fit well with the feel and direction of Swift?
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
More information about the Swift evolution process is available at
I believe the source-breaking change could be avoided by removing the default value for the swiftLangaugeVersions argument and marking that initializer as deprecated. That would still give people a warning when using the deprecated terminology, but still allow them to build with the old name. Since the argument would be required on the deprecated initializer, there would be no ambiguity if neither swiftLanguageVersions nor swiftLanguageModes are passed.
I'm not averse to the rewording, but being focused on SwiftPM, I don't think this solves the most fundamental problem I have with the current situation, which is "how do I refer to the version of Swift 5 that ships with the Swift 6 compiler"? It's not "5.11" and it's not "6", but it's not 100% compatible with 5.10 either.
In source, I think I'm forced to distinguish it as
which is... pretty unpleasant. I think this SE (or a new sibling) should address the language-level conditionalization of code. (And ideally, give a name to this new Swift 5 language iteration)
Removing the default value for swiftLanguageVersions would be a breaking change for developers relying on the default value who have not updated their package manifests to use swift tools version 6.0. A rough survey of public manifest files suggests about 90% of existing manifests rely on the default value.
Oh, that makes sense! In that case you could offer an additional overload with neither swiftLanguageVersions nor swiftLanguageModes that is obsoleted with swift-tools-version 6.0. But I guess it’s up to the language folks whether the cost of adding 2 new initializers is worth the benefit of not breaking any code when updating the swift-tools-version.
First, thank you for your feedback and comments, this was an approach I had not previously considered.
The developer experience in both cases is very similar, an error or a warning with a straightforward renaming fix-it. I believe even with only a warning the vast majority of developers will apply the fix-it immediately after updating a manifest to swift tools version 6.0. The current proposal requires making the change immediately.
For me, adding a new backward-looking init method that will permanently be part of the SwiftPM API in order to allow brief deferral of applying a fix-it (or manually renaming swiftLanguageVersions to swiftLanguageModes) is not a good tradeoff.
One thing I'd like to bring up for consideration is improving the UX for of command line SwiftPM for this option.
Today we have to: swift test -Xswiftc -swift-version -Xswiftc 6 so that'd be swift test -Xswiftc -language-mode -Xswiftc 6 -- the noise of -Xswiftc is quite a mouthful for an option I see myself using a lot because of "let's see if package X builds in 6 mode yet", and it is easier to do this rather than modifying the Package.swift when trying this.
While we don't do this for all compiler option, I'd suggest that the language mode could benefit from the treatment of swiftpm understanding it, and forwarding apropriately, i.e.:
swift test -language-mode 6
is infinitely less scary looking -- especially when I'm showing Swift to people form outside of the Swift ecosystem, any amount of "that's a lot of noise" in initial 5 minutes of some introduction is a big turnoff (it's silly, but that's how people are). I expect this flag to come up in conversations like these because we'll say "oh yeah just use language mode 6!" and they'll want to try it, but be confused about the -Xswiftc parts perhaps
So I'd ask if we can consider teaching swiftpm (built / test) abuit this option, and just have it forward to the compiler (just as -Xswiftc does).
Note that this isn't really what this does, though. It builds all packages in your graph with the language-mode setting, so the result is pretty different compared to modifying the manifest.
@ktoso I definitely understand how an interface that is complicated or noisy can turn people off in a demo and make it hard to get across the overall idea because it is easy for the audience to get caught up in the details.
For me, it seems it would be relatively straightforward in a demo to open the manifest file and change:
// swift-tools-version: 5.10
to:
// swift-tools-version: 6.0
This would:
Demonstrate exactly what a Swift developer would do to enable the Swift 6 language mode in a package
Avoid what @NeoNacho mentions, especially since dependencies may end up generating more errors than the package itself
I don't know how well that might work in your demos, but for me showing that opting in is a one-line change in the manifest file demonstrates simplicity and also shows the actual step Swift developers will take.
The LSG discussed this, and our feeling is that — if this needs to be addressed — it should be addressed in a separate proposal.
Similarly, we feel that this should be discussed as some kind of general SPM mechanism for overriding manifests from the command line rather than a new option specific to language modes.
This proposal should stay focused on the "language mode" terminology change.
Given how late we are in the Swift 6 cycle, I think we might want to deprecate, rather than obsolete, the swiftLanguageVersions: overload of the initializer in packages using swift-tools-version 6. There are surely maintainers who have already finished upgrading their packages for Swift 6 and hard-breaking their manifests at the last minute seems a bit rude.
I'm otherwise in favor of the proposal. The "Swift version" terminology has always been a source of confusion at a level rising to active harm.
The most straightforward way to remove the ambiguity of the two init methods seems to be marking the existing init method as @_disfavoredOverload which allows it coexist with the new method and be deprecated instead of obsoleted.
I have updated the implementation PR with this change.
I hope the terminology change removes that confusion now and for generations of Swift developers to come.
