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

[Javier Soto]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151219/2178ac64/attachment.html>