Hello Swift Community,
This proposal needs to be fleshed out in terms of exact details, but I wanted to pitch it to get feedback on the basic idea.
On the threshold of the community beginning migration to Swift 6 language mode, it seemed it might reduce confusion if the compiler and Swift PM APIs used the more unambiguous terminology. I did not find any previous proposals for this, my apologizes if this had already been pitched.
Thank you for your feedback!
James
Introduction
The term "Swift version” is ambiguous and a source of confusion because it can refer to the toolchain/compiler version or the language mode. This proposal is for the Swift compiler and Swift PM to formalize the term ‘language mode’ in tool options and APIs and deprecate using ‘swift version’ to refer to language mode.
Proposed Solution
The proposed solution is to use the 'language mode' terminology for the appropriate Swift compiler and Swift Package Manager options and API.
Swift compiler
Introduce a -swift-language-mode option that has the same behavior as the existing -swift-version option.
The -swift-version option would continue to work as it currently does, preserving backwards compatibility.
The -swift-language-mode option would be presented in help for the tool while -swift-version may possibly be suppressed.
The option could alternately be named -language-mode.
Swift Package Manager
The Swift Package Manager would have three main API changes limited to manifests >= 6.0:
1. A new Package init method that uses the language mode terminology.
Package(
name: String,
defaultLocalization: \[LanguageTag]? = nil.
platforms: \[SupportedPlatform]? = nil,
products: \[Product] = \[],
dependencies: \[Package.Dependency] = \[],
targets: \[Target] = \[],
swiftLanguageModes: \[SwiftLanguageMode]? = nil,
cLanguageStandard: CLanguageStandard? = nil,
cxxLanguageStandard: CXXLanguageStandard? = nil
)
The parameter swiftLanguageVersions becomes swiftLanguageModes with the type being an optional array of SwiftLanguageMode values instead of SwiftVersion values.
The existing init methods would still exist but would be marked to prefer this new init method.
2. Add SwiftLanguageMode as typealias to SwiftVersion
Introduce SwiftLanguageMode as a typealias of SwiftVersion. (or the other way around if that makes for a smoother transition).
Update all references to SwiftVersion in the API to SwiftLanguageMode
3. Update API proposed in SE-0435: Swift Language Version Per Target:
public struct SwiftSetting \{
// ... other settings
@available(\_PackageDescription, introduced: 6.0)
public static func swiftLanguageMode(
\_ version: SwiftLanguageMode,
\_ condition: BuildSettingCondition? = nil
)
If both are added in the same release, the originally proposed API could potentially be added with the naming changes.
Source compatibility
This proposal is additive and should have no source compatibility issues.
Depending on how to availability is annotated, this proposal could introduce a warning that indicates the developer should move to the new Package init method.
ABI compatibility
I don’t believe this proposal would cause any ABI incompatibility but any incompatibilities should be surfaced and added here during the pitch process.
Alternatives considered
Continue to have an ambiguously named option/setting for language mode with the resulting ongoing confusion and explanations that the ambiguity causes.
