[swift-build-dev] [swift-dev] "Swift 4.1 or Swift 3.3"
jordan_rose at apple.com
Mon Jan 8 19:26:21 CST 2018
> 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.)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-build-dev