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

[David Farler]

> On Dec 18, 2015, at 3:34 PM, Douglas Gregor via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> 
>> On Dec 18, 2015, at 12:29 PM, Chris Lattner via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>>> 
>>> On Dec 18, 2015, at 12:25 PM, Radosław Pietruszewski via swift-evolution <swift-evolution at swift.org> wrote:
>>> 
>>> Sounds like it could be super useful for libraries!
>>> 
>>> How about we drop the quote marks, though? If we have `os(iOS)` and `#available(iOS 9, *)` (in other context), why not `swift(2.2)`?
>> 
>> I agree with Radek.
>> 
>> The argument to use a string is if we wanted to support subversions, e.g. like “#if swift(2.2.1)”.  This requires the parameter to be a string, because 2.2.1 isn’t a valid floating point literal - the lexer will be displeased.
>> 
>> However, I don’t think we *want* the feature to be able to do that.  The most important use case for this feature is to handle syntactic differences across swift versions, and we don’t want those in sub-versions.  Given that, it seems better to keep the syntax clean and simple.
> 
> This feature LGTM, and I also prefer that we drop the quotes. Two levels of version number should be sufficient.
> 
> 	- Doug
> 
>  _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

Chris brought something up that a few of us had discussed in the past: the ambiguity of what the operation does. It's implicitly "current version >= specified version", but I wonder how many people will want to compare otherwise or will assume the comparison is '=='.

We can fix this in two ways:

Option 1: #if swift(<x.y)

or

Option 2: #if swift > x.y

I thought I preferred Option 1 but I think Option 2 reads more how you would expect and somewhat reflects the regular syntax of the language, FWIW. I sketched out both implementations and they're about the same in complexity, so I would suggest Option 2, unless it's a strong goal to keep special sauce in build configurations as "function calls".

Maybe not all of the comparison operators are necessary, but in general this gives some flexibility to arrange checks (newer code at the top or at the bottom) and actually describes what comparison is happening.

David