<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">We already have @- and #-prefixed availability-like constructs, so I would prefer something more specific to the task – I wouldn't want to dilute the meaning of a package name argument by supplying it with the magic package "swift", for example. Changes to the language can be highly disruptive to all Swift code, so that's why I think it warrants its own build configuration. <div class=""><div class=""><br class=""></div><div class="">David</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 20, 2015, at 10:45 PM, David Owens II via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.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=""><div class="">If we are going to support something like this, I’d rather see it be something everyone could leverage as there are many use cases for this feature:</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><font face="Menlo" class="">#if available("package-name", "1.2.*")</font></div><div class=""><font face="Menlo" class="">#endif</font></div></blockquote><div class=""><br class=""></div><div class="">Then at least everyone can opt-in to using it for availability checks. This should of course tie into the Swift Package Manager and use proper semver syntax (might as well use node’s example: <a href="https://docs.npmjs.com/misc/semver" class="">https://docs.npmjs.com/misc/semver</a>).</div><div class=""><br class=""></div><div class=""><div class="">Another solution would be to simply factor out the code into separate files and add each to the appropriate build configuration. Then nothing new needs to be added.</div></div><div class=""><br class=""></div><div class="">-David</div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Dec 20, 2015, at 2:01 PM, James Campbell via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Also in future versions features may go away meaning older libraries may assume that greater than swift 2 is all that is needed to imply compatibility. Also libraries may be written against features they may not know which version of swift it will get into. Additionally certain features aren't available across platforms so how do you know what swift 2 means across platforms ? <br class=""><br class="">Swift version conditionals are a useful fallback but we should also try and make feature conditionals a first class citizen too. <br class=""><br class="">I love the @supports syntax in CSS, if we could do that then that would be awesome :) it's a great way of handling implementations across platforms <br class=""><br class="">Sent from my iPhone<br class=""><br class="">On 20 Dec 2015, at 21:00, Andrey Tarantsov via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""><blockquote type="cite" class=""><blockquote type="cite" class="">I suspect with the race to a stable language, the plan is to design features as if the language were to stay solid.<br class=""></blockquote><br class="">Are you implying that Swift 4 will have zero new features? Nothing that libraries will want to use conditionally when available?<br class=""><br class="">A.<br class=""><br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></blockquote>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></div></blockquote></div><br class="">
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=CeLTg4c6gzJGPH9L0mzZhhYTiKMjRs3ez-2F5o4hxY0YwCbqUN8ZCfwMSQzu7xBDOwdBkQBx9eDHeSnVNtFtr4lOgFccTg7hVG1DEioXAXLZ3FYpgKfH3Q6-2Fmh1C71GlApKh-2FT5DS7fhXQtBmDKTNhp0c6LbZCzY6ZQnL4GRZu0RH4-2FoFp3rw7jnWEeigCUUHyCkQdx-2BTd9lNnIJ-2BPzeVVB9767nNYd1lWIpb6CGORd20-3D" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;" class="">
</div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></div></div></body></html>