-swift-version support and Compiler Control Statements (library author issues)

Apologies in advance, this is likely to be a little long and multiple questions…

I'm trying to find more information on support for -swift-version how it interacts with Compiler Control Statements (specifically swift() and compiler()) and also how we can expect the to be handled with new Swift releases. So…

From looking at current tools and sources, it seems like -swift-version only supports 4, 4.2, and 5.

  • Is there some define process for when a new version will be added to this? i.e. - what's the bar for additions in a release to allow it to be targeted directly?
  • How about when a value will no longer be accepted? i.e. - We dropped Swift 3 support, at what point might the toolchain drop 4 and/or 4.2 support? What's the bar for deciding support should be dropped?

It also appears that what you request for -swift-version gets remapped by the compiler. Using Xcode 11.1's toolchain and -swift-version 4 will pass a if swift(>=4.1) check. Likewise, not using -swift-version or using -swift-version 5 will pass if swift(>=5.1).

  • Is there any defined process on these up-mappings that library authors should rely on? Could a 4 eventually get mapped to 4.2? Could a 4.2 ever get mapped to a 5.x?

Why I'm asking: From a library author pov we need to try to fit in to developers' needs/environments. For SwiftProtobuf, we had said our policy was to support one major version back of the Swift toolchain for compatibility/migration. But with -swift-version this gets more complex. When the 5.2 toolchain is released, that would mean we support back to 4.2, but with 4.2 toolchain taking -swift-version args, does that mean our sources still need to support back to 4.0 language? If the Swift 6 toolchain continues to support -swift-version 4, then it likely means we too must keep our source supporting that language version.

While SwiftPM lets us pick a language version for our library, that doesn't completely help things like SwiftProtobuf because we generate sources for developers, so where they end up compiling the sources is a little more out of our control, and we'd like to ensure things always just work. Odds are developers will put the generated sources in the same module as their App/Library code, so forcing them to adopt/migrate language versions likely wouldn't be well received.

So, generally, any Swift project guidelines on how these things will be handled going forward will help library authors then have better policies around what they support for their customers.

p.s. - yes, we can declare our releases to use higher language versions and if a developer wants to use something older, they use an older release. But as the library author, we are still on the hook for deciding a policy about bug and security fixes for those older releases, so we still need some data to decide how long past language versions will be support by current toolchains to properly declare and provide that support.

A targeted reply: these are the swift language version. There is no language version 5.1, so the latest compiler runs with its version (5.1). Similarly, the Swift 4 compatibility mode runs as the latest version in that mode, which is more recent than 4.1. Prior to the appearance of the compiler control statement, the way to detect Swift 4 mode with the 4.2 tools was to detect swift(>=4.1.50).

Terms of Service

Privacy Policy

Cookie Policy