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

[Ludovic LANDRY]

@felix Swift 3 will stabilize ABI (binary level compatibility) but not the
standard library interfaces (cf. https://github.com/apple/swift-evolution >
Out of Scope > Full source compatibility).

Even is they are stabilized in the future, there can still be some API
added in future Swift versions.


On Sat, Dec 19, 2015 at 12:26 PM, Félix Cloutier <swift-evolution at swift.org>
wrote:

> My understanding is that Swift 3 will stabilize the ABI and the standard
> library interfaces. Given that, I'm not sure what you'd use it for either.
>
> Le 19 déc. 2015 à 14:26:24, Javier Soto via swift-evolution <
> swift-evolution at swift.org> a écrit :
>
> What's the intended most common use case for this? The one that I can
> think of that will show up very often is "declare this function only if
> Swift version is >= X because it relies on some new feature"
> In that case, would it make sense for consistency to also be able to mark
> a function (or type) as "only available on Swift >= X", like you do with
> ios releases? (ie @available(swift, 2.2))
> On Sat, Dec 19, 2015 at 1:28 AM 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
>> >
>> >  _______________________________________________
>> > 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
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
> --
> Javier Soto _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>


-- 
Cordialement,
Ludovic Landry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151219/0c7a446d/attachment.html>