SE-0362: Piecemeal adoption of future language improvements

Overall, a great idea. How about also adding a flag like "-list-optional-features" that I could use on the command line to help me discover what's available?


For people with some types of reading and speech disorders, and for some people whose native tongue is not English, two consecutive words like this that look and sound very similar are not comfortable to read and utter.


I am +1 on the proposal overall.

I read the pitch and the proposal and feel this is a very nice addition.

However, after reading the suggestion from @benrimmington, I believe exposing this to SPM as methods on SwiftSetting would be a better choice.

To me it feels fairly heavyweight to add these parameters to the initializer of Target, even if they are optional.

First, the flags only apply to Swift targets, so the parameters never have use or meaning for C or Cxx targets. Something scoped to Swift targets, such as SwiftSetting seems more appropriate.

Second, enabling future and experimental features is undoubtedly useful, but both seem less fundamental and more esoteric than the other init parameters for a Target.

Since SwiftSetting is the existing SPM mechanism in place for specifying flags to be passed to the Swift compiler, adding the functionality there seems to be the better choice.

Although more verbose, I also think having the method name in SwiftSetting match the setting passed on the command line (with differences only in case style) also makes the mapping extremely clear. Being able to use the existing BuildSettingCondition for SwiftSettings is also a benefit.


Maybe “adoptFeature” is better?

I think it reads better and it clearly conveys intent. It’s even in the proposal title.

1 Like

+1. The gist of the proposa for me: previously, Swift has had ad-hoc command line arguments to enable some features. This proposal replaces these with a general command line argument approach for all future features, as well as SPM support and compile-time checking in the source. All good.

One thing I take issue with: hasFeature construct. I’d argue it can be clearer. Let’s look at the example proposed here:

#if hasFeature(ImplicitOpenExistentials)

It reads "if has feature…” but what has the feature? Swift language? Or the code that is being developed? It is ambiguous.

Let’s compare it to some prior art of similar widely used directives:

#if compiler(>=5.7) - “if compiler is greater than or equal to version…” pretty clear

#if os(macOS) - “if operating system is macOS” - reads smoothly. You could argue that spelling out #if operatingSystem(macOS) would also be quite Swifty.

if #available(iOS 13, *) { - does not read as smoothly, but the argument provides the context that this is talking about available OS versions.

In the spirit of clarity, all these would read unambiguously to me:

#if swiftHasFeature(ImplicitOpenExistentials)
#if languageHasFeature(ImplicitOpenExistentials)
#if hasSwiftFeature(ImplicitOpenExistentials)
#if hasLanguageFeature(ImplicitOpenExistentials)

I realize this is more verbose, but perhaps also more clear. I also note that hasFeature already reads much better than the originally proposed $X. hasFeature feels ambiguous to me because it is not immediately obvious to someone glancing at it that it is talking about Swift features, not the features of the code/app being developed.

1 Like

Great proposal! It will help a lot with preparing our codebases for upcoming changes to the language and make the transition smooth.

I hope my following comment is not too off topic, but on the Swift by Sundell podcast (~ 50:00 mark), Ben Cohen mentions that:

.. [In Swift 6] there will be a language mode that would mean that you will be able to continue building your code in Swift 5 mode even with the new compiler ..

I was looking for some mention of this in the proposal, but it's still unclear if this is really something planned and how it would work.

This is important, because delaying the adoption of some of these new language features may be essential for a large codebase where such migration might take more time. (e.g. fixing all concurrency-related issues is not as "trivial" task as adding any to your existentials). You wouldn't want your entire app to be stuck in Swift 5, but halting product feature development in order to migrate the whole codebase is also not desirable.

In the light of that, the proposal mentions: "[...] future feature flags only accumulate up to the next major Swift language version and are then cleared away, so we don't fork the language into incompatible dialects". I absolutely agree with this, however would be nice to understand if there are any plans for such language mode "downgrades" and how this would play with what is being proposed here.

For me anything is better than the proposed name.

hasFeature(ImplicitOpenExistentials) was proposed because of its symmetry with canImport(Darwin), the one directive you ignored ;)


There are two related kinds of "Swift version" at work here that are distinct, but we often conflate them for convenience. They matter a lot to understanding this proposal, so let me call them out here:

  • Swift tools version: the version number of the compiler itself. The most recent release is Swift 5.6, the one in beta is Swift 5.7.
  • Swift language version: the language version with which we are providing source compatibility.

The Swift tools support multiple Swift language versions. All recent versions (since Swift tools version 5.0) have supported multiple Swift language versions, of which there are currently only three: 4, 4.2, and 5. As the tools evolve, we try to avoid making source-incompatible changes within a Swift language version, although we do introduce extensions to them---for example, you can use async/await in any of those Swift language versions and it's fine.

We have been queuing up source-incompatible changes for Swift language version 6. Swift tools version 6.0 will be the first tools to officially allow the use of Swift language version 6. Those tools will continue to support Swift language versions 4, 4.2, and 5. Your code does not need to move to Swift language version 6 to use Swift tools version 6.0, or 6.1, and so on.

The Swift tools permit interoperability between modules compiled with different Swift language versions. A module compiled with Swift language version 6 can use (and be used by) modules compiled with Swift language version 5 (or 4, or 4.2).

This specific proposal eases the migration path for future features by allowing you to adopt individual future, source-incompatible changes one-by-one, within a given module, each step getting closer to the next Swift language version. At some point, you can switch over to using the new Swift language version (say, 6).



The toolchain version and language version both being called the Swift version and both using numbers in the same range that are sometimes connected to each other but often aren't is something that I've found confusing quite often, and confusing to talk about very often. I've often wished they were just totally decoupled from each other.

As I mentioned previously, I am very much in favor of the proposal overall, but with some feedback and suggestions on the exact details.

I don't think that the 'has' prefix in #if hasFeature() makes the condition more clear and if additional conditions are added with the has prefix as pitched, the prefix makes these conditions more difficult to read.

All but one of the existing compilation conditions essentially omit the verb ‘is’:
#if compiler(>=5.7)
#if os(macOS)
#if arch(arm64)
#if swift(>=4.2)
#if targetEnvironment(simulator)

The one remaining condition is difficult to express without the verb ‘can’ because it is difficult to come up with a single word to indicate importability:
#if canImport(UIKit)

The use of ‘can’ avoids having to use an awkward and less clear construction such as #if importable(UIKit).

For me, this proposed new condition is much closer to the first set of existing conditions above. I think that just as an ‘is’ prefix hasn't been required to clarify the existing conditions, a ‘has’ prefix doesn't add clarity to the proposed condition,

Since the existing conditions have not proved to be confusing:
#if os(macOS)

I don't believe omitting the prefix makes the code less clear or that including it would make the code more clear:

#if feature(ImplicitOpenExistentials)

Although not part of this proposal, the proposed naming convention is also used in a current pitch to conditionally compile based on attribute availability. For me, the following code is very clear without the prefix:

#if attribute(preconcurrency)
protocol P: Sendable { 
    func f()
    func g()

In addition to not seeming to add much additional clarity, if multiple conditions begin with 'has', the prefix becomes visual noise that must always be scanned through to get to the actual thing being conditionalized.

1 Like

How can we extend this to OS version checking? There is a real gap when adopting new capabilities between WWDC and the Fall OS releases.

I understand the desire for such a feature, but it is not in scope for this proposal, which is focused on language features.


Thanks everyone for the insightful review discussion! The Language Workgroup talked about this proposal and the review feedback, and arrived at the following conclusions:

  • The SwiftPM manifest API based on SwiftSetting rather than the target is a better design. This offers more control over when to enable the features, and SwiftSetting already represents build settings specific to Swift.
  • The term "upcoming feature" is less confusing than "future feature". During our verbal discussion, it became abundantly clear that "future feature" is hard to pronounce! We agree that it's best to avoid two consecutive words that are so similar, and "upcoming" is just as clear as "future".
  • The short-circuiting of parsing call syntax should apply to both || and &&.

The author has updated the proposal to incorporate these changes, and the review has been extended through July 11th to gather more discussion on the above modifications. The proposal has also incorporated explanations of Swift language version and Swift tools version, and how these two concepts interact.

These points have received some discussion already, so we'll continue the extended review in this thread.

Thank you,

Holly Borla
Review Manager


I'm still +1 and am glad to see the changes in the proposal.

One small piece of feedback about the proposal itself:

For SwiftPM, the addition of the enableUpcomingFeature function to SwiftSetting represents a one-time break in the manifest file format.

should also mention the enableExperimentalFeature method since it will also be added by this proposal.

Good point, thank you. I've added it via [SE-0362] Clarify that `enableExperimentalFeature` is part of SwiftPM… by DougGregor · Pull Request #1715 · apple/swift-evolution · GitHub.


1 Like

Thanks everyone for participating in this review! The review has concluded and SE-0362 has been accepted.