[swift-build-dev] [swift-dev] "Swift 4.1 or Swift 3.3"

[Jordan Rose]

> On Jan 8, 2018, at 17:18, Chris Lattner <clattner at nondot.org> wrote:
> 
> 
>> On Jan 5, 2018, at 4:19 PM, Jordan Rose via swift-dev <swift-dev at swift.org <mailto:swift-dev at swift.org>> wrote:
>> 
>> Hi, all. Swift 4.1 is off on its own branch and going well, but we never quite came up with an answer for a particular problem developers might have: "am I running a Swift 4.1 compiler?”.
> 
> I agree, this is getting bad.  Ted mentioned that something like __has_feature in clang is probably the best way to go, so people could check the specific thing they care about, instead of a set of global version numbers.
> 
> Another thing that could help is something along the lines of:
> 
> 	#if swift_stdlib(>=5.0)
> 
> which would presumably be active in any language mode when the 5.0 standard library is available.  It would be even better to use a generalized availability system for this: the standard library version could be treated just like Foundation versions are handled, for example.

Yep, though there's a difference between compile-time availability (which is what `#if swift` and `@available(swift, …)` check) and run-time availability (which is what `@available(macOS, …)` and `#available` check). Thus far, availability of features in the standard library has been a compile-time check, but as soon as the standard library starts shipping with Apple's OS, it becomes a run-time check. The conclusion I draw is that there's a good chance we'll end up with different solutions for checking compiler versions vs. checking run-time versions.

(And then there's another thing people have asked for, which is statically checking SDK versions. Thus far they've been able to emulate that with `#if swift` because we've shipped a new Swift with every new Apple SDK, but it's still potentially an interesting feature.)

Jordan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-build-dev/attachments/20180108/6dae91ed/attachment.html>