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

[James Campbell]

I think we should be moving towards feature detection over swift version detection



Sent from my iPhone

> On 20 Dec 2015, at 06:32, Dirk Schreib via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> On 20 Dec 2015, at 07:01, Jordan Rose via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> 
>>> On Dec 19, 2015, at 1:28 , David Farler via swift-evolution <swift-evolution at swift.org> wrote:
>>> 
>>> 
>>>>> 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
>>> 
>>> 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.
>> 
>> I don't like either of these. I especially don't like option 2 because it makes "swift" something magic while user flags are still limited to booleans, and I don't think we're likely to change user flags any time soon. But I don't like option 1 either. We didn't do it for "if #available(…)", and I don't think we need to do it here either.
>> 
>> Jordan
> What about the following syntax?
> #if Swift.sinceVersion( 2, minor: 2 )
> or even better:
> #if Swift.isFeatureAvailable( "foo" )
> The look&feel is standard Swift. Just at compile time. In both cases optional parameter values are possible. 
> 
> - Dirk
> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution