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

[David Owens II]

The @available() and if #available constructs are not sufficient as they fall under the same limitations that your proposal addresses: they require that the non-valid branch not be parsed. For example, an API that has changes with a new language feature, such as variadic generic arguments, would not be able to be defined.

If we look at the grammar, I don’t see why the grammar for “availability-argument” couldn’t look like this:

    availability-argument: (platform-name | language-name | package-name) version.
GRAMMAR OF AN AVAILABILITY CONDITION

 <>availability-condition → #available­(­availability-arguments <https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Statements.html#//apple_ref/swift/grammar/availability-arguments>­)­
 <>availability-arguments → availability-argument <https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Statements.html#//apple_ref/swift/grammar/availability-argument>­  availability-argument <https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Statements.html#//apple_ref/swift/grammar/availability-argument>­,­availability-arguments <https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Statements.html#//apple_ref/swift/grammar/availability-arguments>­
 <>availability-argument → platform-name <https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Statements.html#//apple_ref/swift/grammar/platform-name>­platform-version <https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Statements.html#//apple_ref/swift/grammar/platform-version>­
 <>availability-argument → *­
 <>platform-name → iOS­  iOSApplicationExtension­
 <>platform-name → OSX­  OSXApplicationExtension­
 <>platform-name → watchOS­
 <>platform-version → decimal-digits <https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/LexicalStructure.html#//apple_ref/swift/grammar/decimal-digits>­
 <>platform-version → decimal-digits <https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/LexicalStructure.html#//apple_ref/swift/grammar/decimal-digits>­.­decimal-digits <https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/LexicalStructure.html#//apple_ref/swift/grammar/decimal-digits>­
 <>platform-version → decimal-digits <https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/LexicalStructure.html#//apple_ref/swift/grammar/decimal-digits>­.­decimal-digits <https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/LexicalStructure.html#//apple_ref/swift/grammar/decimal-digits>­.­decimal-digits <https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/LexicalStructure.html#//apple_ref/swift/grammar/decimal-digits>­
I’d further argue that the version argument properly adhere to the semver spec: http://semver.org.

The above change, in addition to the change for the if #available statement to not parse the unavailable path would seem to provide the solution you want to have in addition to the solution that many package developers could use as well.

The nice thing is that this could be done in stages:

1. Add support for the language condition and change #available to not parse the non-valid paths
2. Add support for package names
3. Add support for proper semver versioning.

The only breaking change is #1. When/if semver was supported, the version could still take the decimal digits while adding semver support.

-David

> On Jan 4, 2016, at 4:02 PM, David Farler <dfarler at apple.com> wrote:
> 
> 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 <mailto: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 <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 <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
> 

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