Default swift language version for a given toolchain version

[hassila (Joakim Hassila)]

To follow up from Pitch: [SwiftPM] Swift Language Version Per Target

From original thread:

@ole

+1 on the general idea of the pitch. It's important to have per-target control over the Swift language version.

@hborla

Personally, I don't think the default when using Swift 6.0 tools should be Swift 6 mode - that's not the default in the compiler, because otherwise source compatibility won't be maintained for existing code.

Apologies if this isn't the thread to debate this point, but I find it very surprising that the default language version of the Swift 6.0 compiler is not Swift 6. Is this the plan for the actual Swift 6.0 release?

Does this mean that going forward, we'll have to pass -swift-version 6 to all CLI swift/swiftc invocations if we want to use Swift 6 features? I would find that very odd. Or is there a plan to change the default in a later Swift 6.x compiler release? (which would also be odd)

@hassila

I’ll not elaborate the points already made on why it would make sense to default the language version to the toolchain version, but just add two more minor point in favor of that:

1. If we want people to migrate to the latest language version defaulting to it is crucial over time as we’d expect usage of swift to grow
2. More importantly, it would set a strange precedent for future major language versions. If we’d default to swift 5 for the swift 6 toolchain, what should be the default for the swift 7 toolchain (and why?). Much clearer to link those and provide the escape hatches for migration outlined above.

To break out the discussion about what the default language version should be for a given toolchain version to a new thread;

I’d argue for matching the toolchain and language versions by default with escape hatches as outlined in the related thread for migration.

[hborla (Holly Borla)]

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.

@ole

Does this mean that going forward, we'll have to pass -swift-version 6 to all CLI swift/swiftc invocations if we want to use Swift 6 features?

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.

@hassila

If we want people to migrate to the latest language version defaulting to it is crucial over time as we’d expect usage of swift to grow

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.

@hassila

More importantly, it would set a strange precedent for future major language versions. If we’d default to swift 5 for the swift 6 toolchain, what should be the default for the swift 7 toolchain (and why?). Much clearer to link those and provide the escape hatches for migration outlined above.

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.

[jrose (Jordan Rose)]

@hborla

That code cannot break just by upgrading to Swift 6.0 tools.

I think it’s worth being precise about what “upgrading to 6.0 tools” means. Switching to Xcode 16 or whatever wouldn’t break anything, because all Package.swift files start with a version number. (And I agree that the interpretation of Package.swift files without a version number shouldn’t change.)

So we’re talking about someone who has edited their Package.swift to say “6.0” at the top. Why can’t that have breaking changes and a little migration guide?

[FranzBusch]

I agree with @jrose here. If I manually change the tools version in my package manifest to 6.0 I expect the default language to also change.

[James_Dempsey]

I think it's also important to note that in the context of SwiftPM package and Xcode projects, explicit
-swift-version flags are already typically passed to the compiler.

I think this flag is always passed for SwiftPM packages.

Xcode project templates currently automatically define a SWIFT_VERSION build setting of 5 which is passed to the compiler. Xcode builds fail if no SWIFT_VERSION is set. (Thank you @NeoNacho Default swift language version for a given toolchain version - #9 by NeoNacho)

So, in many existing developer contexts, the compiler default language mode is already overridden.

I think this ends up being three different decisions about language version/mode:

• How SwiftPM chooses the default language mode it passes to the compiler
• The language mode set in Xcode templates
• The compiler default language mode

SwiftPM

For SwiftPM, I believe that SwiftPM should pass the -swift-version 6 flag by default once a package has been updated to declare // swift-tools-version:6.0.

It is an explicit opt-in for existing packages so swift-tools-version 5.x packages continue to use version 5 by default. (Pitch: [SwiftPM] Swift Language Version Per Target - #12 by James_Dempsey)

Xcode

For Xcode, since it's proprietary, as a community, we don't really have insight into when templates might change to use SWIFT_VERSION 6.

But even then, most existing Xcode projects will continue building with SWIFT_VERSION 5 since that has been part of templates for a long while now.

I could also imagine Xcode checking if a project does not have a SWIFT_VERSION build setting and notifying the user and letting them choose between 5 and 6.

One thing I do hope Apple-internal folks guard against is encouraging SWIFT_VERSION 6 as one of the 'recommended build setting updates' that appear when opening a project with a new Xcode version.

Compiler Default

I don't have any statistics as to how much Swift is compiled via SwiftPM commands vs xcodebuild of Xcode projects vs 'bare' use of calling the compiler using things like makefiles.

But, I would imagine a great deal of compilation is in the context of building SwiftPM packages and Xcode projects, which override the compiler default.

I could see the built-in default going either way.

UPDATE: Updated with information that Xcode builds fail if SWIFT_VERSION build setting is not present.

[hborla (Holly Borla)]

@jrose

I think it’s worth being precise about what “upgrading to 6.0 tools” means. Switching to Xcode 16 or whatever wouldn’t break anything, because all Package.swift files start with a version number.

Yes, sorry! I specifically mean a change that causes you to use a Swift 6.0 compiler, such as downloading and trying out a 6.0 nightly toolchain with an existing project, and not making any source changes. I'm okay with the default language mode that SwiftPM passes to change when you bump your package manifest to require 6.0 tools. I'm not okay with changing the default language mode in the Swift 6.0 compiler itself. The default in the compiler impacts all kinds of projects, not just packages.

[0xTim (Tim)]

Just to clarify because I think everyone is actually on the same page here:

• Take an existing package with the tools version set to 5.10, for example and build it with the Swift 6 compiler - Swift 5 language mode
• New package/updated package with the tools version set to 6.0 and build it with the Swift 6 compiler - Swift 6 language mode (and swift build will use the Swift 6 language mode for building a package)

That's the current aim correct?

The only clarification I think is if I have a package that has specified the tools version as 6.0 but it pulls in dependencies that still use 5.10 - the 6.0 target will use the Swift 6 language mode but the dependencies will still be built with the Swift 5 language mode

[NeoNacho (Boris Buegling)]

@James_Dempsey

Xcode project templates currently automatically define a SWIFT_VERSION build setting of 5 which is passed to the compiler. But, developers could remove the build setting. (Also, I haven't explored every Xcode template to ensure this is always set.)

They actually cannot do that since if they do, they'll get a build error:

Value for SWIFT_VERSION cannot be empty.

This has been the case for a long time, at least since the introduction of the new build system.

[James_Dempsey]

@NeoNacho

@James_Dempsey

Xcode project templates currently automatically define a SWIFT_VERSION build setting of 5 which is passed to the compiler. But, developers could remove the build setting. (Also, I haven't explored every Xcode template to ensure this is always set.)

They actually cannot do that since if they do, they'll get a build error:

Value for SWIFT_VERSION cannot be empty.

This has been the case for a long time, at least since the introduction of the new build system.

Thank you, I'll update my original post to reflect this.

[hassila (Joakim Hassila)]

Then I think we are on the same page too, I got the impression that it wouldn’t be enough to just edit the tools version in a package manifest to get the new language mode, which would have been a bit unexpected.

I can understand the pragmatism of not wanting to change the default version when using the compiler directly, but that’ll mean then that version 5 is basically forever the default? Swift toolchain version 10 would then still default to swift language version 5 with the same argument - to not break any old code out there.that will over time be stranger and stranger…

Perhaps should start issuing a warning if the language version isn’t specifically specified from the command line? Or as a fix-it if trying to use new features (which might be hard?). Just seems like a nice experience for someone who wants to build a single file to test the language out would get the version of the language that is current and not a “random” version from years ago which might not then compile?

[hassila (Joakim Hassila)]

Or maybe even add an environment sledgehammer setting SWIFT_LANGUAGE_VERSION which would be picked up, the we could change the toolchain version and for any code base requiring swift 5 language mode it can be set in the environment.

[Max_Desiatov]

I don't think there's a need to introduce yet another environment variable to handle a build setting.

In general, environment variables are stringly typed, hard to manage, and hard to discover.

If you need a sledgehammer, you can build with swift build -Xswiftc -swift-version -Xswiftc 6, which will apply the language version setting to parts of the build graph configured for a target triple. And at least you'll see an error message if you make a typo, unlike with environment variables.

[hassila (Joakim Hassila)]

More than fair enough. The at least start warning that swift language mode should be explicitly passed so we can at least start pushing against having a toolchain version and language version get in sync in the future. It just rubs be the wrong way to have the swift toolchain version 32 ship with language version 5