@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@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@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@swift.org> wrote: > >> >> > On Dec 18, 2015, at 3:34 PM, Douglas Gregor via swift-evolution < >> swift-evolution@swift.org> wrote: >> > >> >> >> >> On Dec 18, 2015, at 12:29 PM, Chris Lattner via swift-evolution < >> swift-evolution@swift.org> wrote: >> >> >> >>> >> >>> On Dec 18, 2015, at 12:25 PM, Radosław Pietruszewski via >> swift-evolution <swift-evolution@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@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@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution >> > -- > Javier Soto _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution > > > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution > > -- Cordialement, Ludovic Landry
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution