Piecemeal adoption of Swift 6 improvements in Swift 5.x

And for those interested in the implementation details, I have a pull request up at Piecemeal adoption of future language improvements by DougGregor · Pull Request #59055 · apple/swift · GitHub for the compiler pieces.

Doug

5 Likes

I realize you have not put the proposal through the pitch phase yet but I had one suggestion to consider before you do.

All compiler conditions except canImport() omit the word is or has to define the condition.

I think #if feature(FeatureX) is as clear as #if targetEnvironment(simulator), #if compiler(swift >= 5.1) or any of the other existing conditions without a verb.

The condition canImport() seems to be an outlier because there isn't a single noun that adequately explains the condition.

Possibly consider #if feature() instead of #if hasFeature() since it follows the existing naming convention of all but one compilation condition and seems it would be just as clear and understandable to read.

5 Likes

That sounds like a really concise way to phrase it. It would also be an alternative to using fragile build flags in package manifests. Import availabilities and (maybe) platforms are extremely dynamic; so are the plethora of Swift 6 features we want to test out in Swift 5. By dynamic, I mean it would take unreasonably long to make each one an official part of the Swift compiler and then support its specific build flag in the far future. We need something where support for the opt-in feature can be quickly added or dropped and not promised to be maintained indefinitely.

1 Like

I don't know if you read through the full proposal Douglas Gregor has written up:

I am guessing the proposal will go into pitch phase sometime after WWDC, since it is a pretty busy week for the core team, but I didn't want to forget my naming suggestion.

1 Like

The only omitted verb is "is": there is only one target environment, compiler version, etc. at build time, so the conditional asks what that target environment is, or what that compiler version is, etc. It would be inapt to write #if feature, by contrast, as one is not asking what "the" feature is at compile time, since there's more than one feature that may or may not be enabled just like there's more than one library that can or cannot be imported.

1 Like

The core team generally avoids scheduling proposal reviews over the week of WWDC, since a large chunk of the community is focused on that conference. I expect this proposal to go into review shortly afterward based on the responses in this pitch.

Doug

5 Likes

A bikeshed on --enable-experimental-feature: Would --enable-experimental-future-feature be better? I think it communicates an extra layer of caution needed, and the longer flag name adds a little bit more friction so people are (slightly) less inclined to use it.

Would it be a good idea to also add --enable-all-(experimental-)future-features to enable all, along with --disable-(experimental-)future-feature flags to opt out specific features when the former flag is set.

I don't think so. Experimental features are not necessarily future features---they might turn out to be a bad idea, or get changed or renamed.

I don't think we should do that. These "future" features are source-breaking, so adding a new one into your build needs to be a deliberate choice... not something that comes from installing a new toolchain.

Doug

10 Likes

I've kicked this off for review here. Thanks all for the discussion so far, and please take any further feedback over to the review thread!

1 Like