> On Jan 8, 2018, at 17:18, Chris Lattner <clatt...@nondot.org> wrote: > > >> On Jan 5, 2018, at 4:19 PM, Jordan Rose via swift-dev <swift-dev@swift.org >> <mailto:swift-dev@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
_______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
