<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Jan 8, 2018, at 17:18, Chris Lattner <<a href="mailto:clattner@nondot.org" class="">clattner@nondot.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jan 5, 2018, at 4:19 PM, Jordan Rose via swift-dev <<a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=us-ascii" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">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 <i class="">compiler?”.</i></div></div></blockquote><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Another thing that could help is something along the lines of:</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>#if swift_stdlib(>=5.0)</div><div class=""><br class=""></div><div class="">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.</div></div></div></div></blockquote><br class=""></div><div>Yep, though there's a difference between <i class="">compile-time</i> availability (which is what `#if swift` and `@available(swift, …)` check) and <i class="">run-time availability</i> (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.</div><div><br class=""></div><div>(And then there's <i class="">another</i> thing people have asked for, which is statically checking <i class="">SDK</i> 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.)</div><div><br class=""></div><div>Jordan</div><br class=""></body></html>