[swift-evolution] [Proposal] Swift 2.2: #if swift language version

David Farler dfarler at apple.com
Mon Jan 4 18:02:33 CST 2016


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. 

David

> On Dec 20, 2015, at 10:45 PM, David Owens II via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 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:
> 
> #if available("package-name", "1.2.*")
> #endif
> 
> 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: https://docs.npmjs.com/misc/semver <https://docs.npmjs.com/misc/semver>).
> 
> 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.
> 
> -David
> 
>> On Dec 20, 2015, at 2:01 PM, James Campbell via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> 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 ? 
>> 
>> Swift version conditionals are a useful fallback but we should also try and make feature conditionals a first class citizen too. 
>> 
>> 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 
>> 
>> Sent from my iPhone
>> 
>> On 20 Dec 2015, at 21:00, Andrey Tarantsov via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>>>> I suspect with the race to a stable language, the plan is to design features as if the language were to stay solid.
>>> 
>>> Are you implying that Swift 4 will have zero new features? Nothing that libraries will want to use conditionally when available?
>>> 
>>> A.
>>> 
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160104/25781a26/attachment.html>


More information about the swift-evolution mailing list