SE-0441: Formalize 'language mode' terminology

John_McCall · 2024-07-15T21:02:13.910Z

Hello, Swift community.

The review of SE-0441: Formalize 'language mode' terminology begins now and runs until July 29th.

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

https://github.com/apple/swift-evolution/blob/main/process.md

Thank you,

John McCall
Review Manager

j-f1 · 2024-07-15T22:55:58.442Z

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.

KeithBauerANZ · 2024-07-15T23:07:05.983Z

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

#if swift(>=5.10) && swift(<6.0) && compiler(>=6.0)

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)

James_Dempsey · 2024-07-15T23:18:51.135Z

KeithBauerANZ:

I think this SE (or a new sibling) should address the language-level conditionalization of code.

Yes, the Future Directions section of the proposal discusses a languageMode() compilation condition which will be pitched separately.

James_Dempsey · 2024-07-15T23:26:41.980Z

j-f1:

I believe the source-breaking change could be avoided by removing the default value for the swiftLangaugeVersions argument and marking that initializer as deprecated.

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.

j-f1 · 2024-07-16T01:05:44.030Z

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.

James_Dempsey · 2024-07-18T12:32:35.128Z

j-f1:

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.

ktoso · 2024-07-19T00:00:52.959Z

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).

NeoNacho · 2024-07-19T05:33:03.569Z

ktoso:

"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.

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.

James_Dempsey · 2024-07-19T18:53:14.937Z

NeoNacho:

ktoso:

"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.

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.

NeoNacho · 2024-07-19T20:16:44.075Z

BTW, there's also a tools-version --set command that might help with the workflow here:

❯ swift package tools-version --set 6.0 

/tmp/foobar2 main*
❯ git diff
diff --git a/Package.swift b/Package.swift
index b510587..480f367 100644
--- a/Package.swift
+++ b/Package.swift
@@ -1,4 +1,4 @@
-// swift-tools-version: 5.10
+// swift-tools-version: 6.0

benrimmington · 2024-07-19T23:00:51.964Z

Xcode isn't open source, but would it be possible to change the build setting?

Title:
"Swift Language ~~Version~~ Mode"
Summary (Quick Help):
"The language ~~version~~ mode used to compile the target's Swift code."
Name:
SWIFT_VERSION → SWIFT_LANGUAGE_MODE
Values:
4.0 → 4
4.2
5.0 → 5
6.0 → 6

(The name and values are visible in "project.pbxproj" and "*.xcconfig" files.)

James_Dempsey · 2024-07-19T23:14:07.704Z

If the proposal is accepted, and it is in a release, I was planning on filing an Xcode Feedback asking for this.

My hope is that Xcode would add a new build setting adopting the new naming/values once the proposed changes are available.

John_McCall · 2024-07-23T22:08:18.575Z

KeithBauerANZ:

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.

The LSG discussed this, and our feeling is that — if this needs to be addressed — it should be addressed in a separate proposal.

ktoso:

One thing I'd like to bring up for consideration is improving the UX for of command line SwiftPM for this option.

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.

beccadax · 2024-07-23T23:28:43.559Z

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.

ktoso · 2024-07-24T08:53:28.226Z

John_McCall:

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.

That sounds fair and worth revisiting in a separate proposal, thanks for discussing it

James_Dempsey · 2024-07-24T12:42:03.302Z

beccadax:

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.

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.

beccadax:

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.

I hope the terminology change removes that confusion now and for generations of Swift developers to come.

John_McCall · 2024-08-05T20:12:00.141Z

SE-0441 has been accepted with the revision above that only deprecates swiftLanguageVersions: rather than obsoleting it.

I'd like to thank everyone who read the proposal and participated in this review.

John McCall
Review Manager

John_McCall · 2024-08-05T20:12:03.745Z