[swift-evolution] [Proposal] Swift 2.2: #if swift language version

Chris Lattner clattner at apple.com
Mon Dec 21 13:30:28 CST 2015

> On Dec 20, 2015, at 11:28 AM, James Campbell via swift-evolution <swift-evolution at swift.org> wrote:
> I think we should be moving towards feature detection over swift version detection

I’m a huge fan of feature detection (__has_feature and __has_include in Clang are some of my contributions), but I don’t think that makes sense here.  We want swift to have a linear and consistent version numbering scheme.  This means that "Swift 2.2” and “Swift 3.0” should mean something across all the potential implementations, at least in terms of the compiler and standard library interfaces.  I do agree that something like “has package” could make sense.

Someone upthread asked for a specific use-case, here it is: 

- At some point in time, Swift 3 will be widely available to developers in Beta form, but not yet finalized.
- At this point Swift 2.2 will be finalized and lots of code will be building against Swift 2.2. 
- Swift 3 will be source incompatible with Swift 2.2.

It would be unfortunate if the huge number of frequently used packages (e.g. AlamoFire as one random example) would have to make a choice between the two, or fork their own development.  Having #if checks against versions numbers for the months where Swift 3 is in development - but not yet finalized - can ease pain for teams trying to maintain their code.  Sometime after Swift 3 is out the door, they can then remove the old swift 2.2 support code and move on with life.


More information about the swift-evolution mailing list