[swift-evolution] [Proposal] Swift 2.2: #if swift language version
dfarler at apple.com
Sat Dec 19 15:51:13 CST 2015
That is a fair point of comparison, although this should work for both statements and declarations, in which case the extra attribute style would be redundant. Maybe the implicit >= is good enough. I'd like to keep it as simple as possible.
> On Dec 19, 2015, at 11:26, Javier Soto <javier.api at gmail.com> wrote:
> 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)
>> 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.
>> swift-evolution mailing list
>> swift-evolution at swift.org
> Javier Soto
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution