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

Sat Dec 19 15:26:18 CST 2015

That's not how I read it. The stable ABI point says (emphasis mine):

> Stabilize the binary interface (ABI) to guarantee a level of binary compatibility moving forward. This involves finalizing runtime data structures, name mangling, calling conventions, and so on, as well as finalizing some of the details of the language itself that have an impact on its ABI. **Stabilizing the ABI also extends to the Standard Library, its data types, and core algorithms.** Successful ABI stabilization means that applications and libraries compiled with future versions of Swift can interact at a binary level with applications and libraries compiled with Swift 3.0, even if the source language changes.

If Swift 3 succeeds with this goal, there can be new interfaces in the standard library, but existing interfaces will be final.

My experience with other languages is that even when it's possible to determine if the compiler/library supports some feature, unless you're a Boost maintainer, people tend to target one version of the language anyway, either the older one using a workaround portable to the newer version, or the new version without regards to people stuck behind.

The one notable exception I can think of is Python 2 vs Python 3, but that's because the "ABI" underwent very important changes.

That's why I'm asking what it would be used for.

> Le 19 déc. 2015 à 15:52:08, Ludovic LANDRY <landryludovic at gmail.com> a écrit :
> 
> @felix Swift 3 will stabilize ABI (binary level compatibility) but not the standard library interfaces (cf. https://github.com/apple/swift-evolution <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 <mailto: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 <mailto: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 <mailto:swift-evolution at swift.org>> wrote:
>> 
>> > On Dec 18, 2015, at 3:34 PM, Douglas Gregor via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> >
>> >>
>> >> On Dec 18, 2015, at 12:29 PM, Chris Lattner via swift-evolution <swift-evolution at swift.org <mailto: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 <mailto: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 <mailto:swift-evolution at swift.org>
>> > https://lists.swift.org/mailman/listinfo/swift-evolution <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 <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> -- 
>> Javier Soto  _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <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/7c0b25f7/attachment.html>