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

[David Owens II via swift-evolution]

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 
­)­
 <>availability-arguments → availability-argument 
­
  availability-argument 
­,­availability-arguments
 
­
 <>availability-argument → platform-name 
­platform-version
 
­
 <>availability-argument → *­
 <>platform-name → iOS­  iOSApplicationExtension­
 <>platform-name → OSX­  OSXApplicationExtension­
 <>platform-name → watchOS­
 <>platform-version → decimal-digits 
­
 <>platform-version → decimal-digits 
­.­decimal-digits
 
­
 <>platform-version → decimal-digits 
­.­decimal-digits
 
­.­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  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 
>> mailto:swift-evolution@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 
>> ).
>> 
>> Another solution would be to simply factor out the code into separate files 
>> and add each to the appropriate 

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

[David Farler via swift-evolution]

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 
>  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 
> ).
> 
> 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 
>> mailto:swift-evolution@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 
>> mailto:swift-evolution@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@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Rod Brown via swift-evolution]

Definitely a +1 from me.

- Rod

> On 3 Jan 2016, at 9:48 PM, Goffredo Marocchi via swift-evolution 
>  wrote:
> 
> +1 from me as well, supporting conditional compilation when the two versions 
> of foundation differ and may differ for the foreseeable future seems a must 
> on this end.
> 
> Sent from my iPhone
> 
>> On 3 Jan 2016, at 10:12, Drew Crawford via swift-evolution 
>>  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
>> 
>> Big +1.
>> 
>> I've asked specifically to get some kind of conditional compilation on 
>> corelibs-foundation being used.  corelibs-founcation is currently 
>> incompatible with Darwin Foundation, and so it is impractical to make a 
>> single codebase build for both.
>> 
>> But building the same application against both Foundations and spotting 
>> differences is one of the important ways we're going to spot bugs.
>> 
>> So I think the code quality of Foundation ultimately hinges on getting some 
>> feature like this in the language.
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[David Owens II via swift-evolution]

I could (assuming I’m the David you’re referring to), though it will probably 
be towards the end of the week or early next week before I get a chance to get 
to it.

-David

> On Jan 4, 2016, at 1:03 PM, Drew Crawford  wrote:
> 
> The swift package manager is currently considering its own define 
> ,
>  so it's now the second official project that could benefit from this syntax.
> 
> David, any interest in writing this up?
> 
>> On Jan 3, 2016, at 4:48 AM, Goffredo Marocchi > > wrote:
>> 
>> +1 from me as well, supporting conditional compilation when the two versions 
>> of foundation differ and may differ for the foreseeable future seems a must 
>> on this end.
>> 
>> Sent from my iPhone
>> 
>> On 3 Jan 2016, at 10:12, Drew Crawford via swift-evolution 
>> mailto:swift-evolution@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
>>> 
>>> Big +1.
>>> 
>>> I've asked specifically to get some kind of conditional compilation on 
>>> corelibs-foundation 
>>> 
>>>  being used.  corelibs-founcation is currently incompatible with Darwin 
>>> Foundation, and so it is impractical to make a single codebase build for 
>>> both.
>>> 
>>> But building the same application against both Foundations and spotting 
>>> differences is one of the important ways we're going to spot bugs.
>>> 
>>> So I think the code quality of Foundation ultimately hinges on getting some 
>>> feature like this in the language.
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> 
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Drew Crawford via swift-evolution]

The swift package manager is currently considering its own define 
,
 so it's now the second official project that could benefit from this syntax.

David, any interest in writing this up?

> On Jan 3, 2016, at 4:48 AM, Goffredo Marocchi  wrote:
> 
> +1 from me as well, supporting conditional compilation when the two versions 
> of foundation differ and may differ for the foreseeable future seems a must 
> on this end.
> 
> Sent from my iPhone
> 
> On 3 Jan 2016, at 10:12, Drew Crawford via swift-evolution 
> mailto:swift-evolution@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
>> 
>> Big +1.
>> 
>> I've asked specifically to get some kind of conditional compilation on 
>> corelibs-foundation 
>> 
>>  being used.  corelibs-founcation is currently incompatible with Darwin 
>> Foundation, and so it is impractical to make a single codebase build for 
>> both.
>> 
>> But building the same application against both Foundations and spotting 
>> differences is one of the important ways we're going to spot bugs.
>> 
>> So I think the code quality of Foundation ultimately hinges on getting some 
>> feature like this in the language.
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Goffredo Marocchi via swift-evolution]

+1 from me as well, supporting conditional compilation when the two versions of 
foundation differ and may differ for the foreseeable future seems a must on 
this end.

Sent from my iPhone

> On 3 Jan 2016, at 10:12, Drew Crawford via swift-evolution 
>  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
> 
> Big +1.
> 
> I've asked specifically to get some kind of conditional compilation on 
> corelibs-foundation being used.  corelibs-founcation is currently 
> incompatible with Darwin Foundation, and so it is impractical to make a 
> single codebase build for both.
> 
> But building the same application against both Foundations and spotting 
> differences is one of the important ways we're going to spot bugs.
> 
> So I think the code quality of Foundation ultimately hinges on getting some 
> feature like this in the language.
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Drew Crawford via swift-evolution]

> 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

Big +1.

I've asked specifically to get some kind of conditional compilation on 
corelibs-foundation 

 being used.  corelibs-founcation is currently incompatible with Darwin 
Foundation, and so it is impractical to make a single codebase build for both.

But building the same application against both Foundations and spotting 
differences is one of the important ways we're going to spot bugs.

So I think the code quality of Foundation ultimately hinges on getting some 
feature like this in the language.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Chris Lattner via swift-evolution]

> On Dec 20, 2015, at 11:28 AM, James Campbell via swift-evolution 
>  wrote:
> 
> I think we should be moving towards feature detection over swift version 
> detection

I’m a huge fan of feature detection (__has_feature and __has_include in Clang 
are some of my contributions), but I don’t think that makes sense here.  We 
want swift to have a linear and consistent version numbering scheme.  This 
means that "Swift 2.2” and “Swift 3.0” should mean something across all the 
potential implementations, at least in terms of the compiler and standard 
library interfaces.  I do agree that something like “has package” could make 
sense.

Someone upthread asked for a specific use-case, here it is: 

- At some point in time, Swift 3 will be widely available to developers in Beta 
form, but not yet finalized.
- At this point Swift 2.2 will be finalized and lots of code will be building 
against Swift 2.2. 
- Swift 3 will be source incompatible with Swift 2.2.

It would be unfortunate if the huge number of frequently used packages (e.g. 
AlamoFire as one random example) would have to make a choice between the two, 
or fork their own development.  Having #if checks against versions numbers for 
the months where Swift 3 is in development - but not yet finalized - can ease 
pain for teams trying to maintain their code.  Sometime after Swift 3 is out 
the door, they can then remove the old swift 2.2 support code and move on with 
life.

-Chris

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[David Owens II via swift-evolution]

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).

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 
>  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 
>  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@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[James Campbell via swift-evolution]

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 
 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@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Andrey Tarantsov via swift-evolution]

> 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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Andrey Tarantsov via swift-evolution]

> My experience with other languages is that [...] unless you're a Boost 
> maintainer, people tend to target one version of the language anyway, either 
> the older one using a workaround portable to the newer version, or the new 
> version without regards to people stuck behind.

That's not how it works with Apple. Every summer we get a new beta version of 
Xcode with a new version of Swift, which we should use for all new developments 
(because it'll become the shipping version in the fall), but we have to use an 
older one for App Store-ready products if we want to be able to submit updates. 
So libraries do often support several versions of the language.

Just look the libraries that still support dual ARC/non-ARC modes, which is 
something that's not necessary at all.

A.

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Rod Brown via swift-evolution]

While that is true, I suspect with the race to a stable language, the plan is 
to design features as if the language were to stay solid. I wonder about the 
wisdom in designing part of the language to handle the fact they are not 
finished designing the language.

Perhaps as an compromise, they could treat different versions of swift as 
features in and of themselves?

- Rod

> On 21 Dec 2015, at 7:33 AM, Radosław Pietruszewski via swift-evolution 
>  wrote:
> 
> But the thing is, right now it’s not just new features that show up in new 
> releases. We also have breaking syntax changes.
> 
> Feature detection make more sense in the future (perhaps one day we could 
> have an “unstable” Swift branch with experimental features), but right now 
> version detection makes more sense.
> 
> — Radek
> 
>> On 20 Dec 2015, at 20:28, James Campbell via swift-evolution 
>>  wrote:
>> 
>> I think we should be moving towards feature detection over swift version 
>> detection
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Radosław Pietruszewski via swift-evolution]

But the thing is, right now it’s not just new features that show up in new 
releases. We also have breaking syntax changes.

Feature detection make more sense in the future (perhaps one day we could have 
an “unstable” Swift branch with experimental features), but right now version 
detection makes more sense.

— Radek

> On 20 Dec 2015, at 20:28, James Campbell via swift-evolution 
>  wrote:
> 
> I think we should be moving towards feature detection over swift version 
> detection

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[James Campbell via swift-evolution]

I think we should be moving towards feature detection over swift version 
detection



Sent from my iPhone

> On 20 Dec 2015, at 06:32, Dirk Schreib via swift-evolution 
>  wrote:
> 
> 
>> On 20 Dec 2015, at 07:01, Jordan Rose via swift-evolution 
>>  wrote:
>> 
>> 
>>> On Dec 19, 2015, at 1:28 , David Farler via swift-evolution 
>>>  wrote:
>>> 
>>> 
> On Dec 18, 2015, at 3:34 PM, Douglas Gregor via swift-evolution 
>  wrote:
> 
> 
>> On Dec 18, 2015, at 12:29 PM, Chris Lattner via swift-evolution 
>>  wrote:
>> 
>> 
>> On Dec 18, 2015, at 12:25 PM, Radosław Pietruszewski via swift-evolution 
>>  wrote:
>> 
>> Sounds like it could be super useful for libraries!
>> 
>> How about we drop the quote marks, though? If we have `os(iOS)` and 
>> `#available(iOS 9, *)` (in other context), why not `swift(2.2)`?
> 
> I agree with Radek.
> 
> The argument to use a string is if we wanted to support subversions, e.g. 
> like “#if swift(2.2.1)”.  This requires the parameter to be a string, 
> because 2.2.1 isn’t a valid floating point literal - the lexer will be 
> displeased.
> 
> However, I don’t think we *want* the feature to be able to do that.  The 
> most important use case for this feature is to handle syntactic 
> differences across swift versions, and we don’t want those in 
> sub-versions.  Given that, it seems better to keep the syntax clean and 
> simple.
 
 This feature LGTM, and I also prefer that we drop the quotes. Two levels 
 of version number should be sufficient.
 
   - Doug
>>> 
>>> Chris brought something up that a few of us had discussed in the past: the 
>>> ambiguity of what the operation does. It's implicitly "current version >= 
>>> specified version", but I wonder how many people will want to compare 
>>> otherwise or will assume the comparison is '=='.
>>> 
>>> We can fix this in two ways:
>>> 
>>> Option 1: #if swift(>> 
>>> or
>>> 
>>> Option 2: #if swift > x.y
>>> 
>>> I thought I preferred Option 1 but I think Option 2 reads more how you 
>>> would expect and somewhat reflects the regular syntax of the language, 
>>> FWIW. I sketched out both implementations and they're about the same in 
>>> complexity, so I would suggest Option 2, unless it's a strong goal to keep 
>>> special sauce in build configurations as "function calls".
>>> 
>>> Maybe not all of the comparison operators are necessary, but in general 
>>> this gives some flexibility to arrange checks (newer code at the top or at 
>>> the bottom) and actually describes what comparison is happening.
>> 
>> I don't like either of these. I especially don't like option 2 because it 
>> makes "swift" something magic while user flags are still limited to 
>> booleans, and I don't think we're likely to change user flags any time soon. 
>> But I don't like option 1 either. We didn't do it for "if #available(…)", 
>> and I don't think we need to do it here either.
>> 
>> Jordan
> What about the following syntax?
> #if Swift.sinceVersion( 2, minor: 2 )
> or even better:
> #if Swift.isFeatureAvailable( "foo" )
> The look&feel is standard Swift. Just at compile time. In both cases optional 
> parameter values are possible. 
> 
> - Dirk
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[David Farler via swift-evolution]

> On Dec 19, 2015, at 22:01, Jordan Rose  wrote:
> 
> 
>> On Dec 19, 2015, at 1:28 , David Farler via swift-evolution 
>>  wrote:
>> 
>> 
 On Dec 18, 2015, at 3:34 PM, Douglas Gregor via swift-evolution 
  wrote:
 
 
> On Dec 18, 2015, at 12:29 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
> 
> On Dec 18, 2015, at 12:25 PM, Radosław Pietruszewski via swift-evolution 
>  wrote:
> 
> Sounds like it could be super useful for libraries!
> 
> How about we drop the quote marks, though? If we have `os(iOS)` and 
> `#available(iOS 9, *)` (in other context), why not `swift(2.2)`?
 
 I agree with Radek.
 
 The argument to use a string is if we wanted to support subversions, e.g. 
 like “#if swift(2.2.1)”.  This requires the parameter to be a string, 
 because 2.2.1 isn’t a valid floating point literal - the lexer will be 
 displeased.
 
 However, I don’t think we *want* the feature to be able to do that.  The 
 most important use case for this feature is to handle syntactic 
 differences across swift versions, and we don’t want those in 
 sub-versions.  Given that, it seems better to keep the syntax clean and 
 simple.
>>> 
>>> This feature LGTM, and I also prefer that we drop the quotes. Two levels of 
>>> version number should be sufficient.
>>> 
>>>- Doug
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> Chris brought something up that a few of us had discussed in the past: the 
>> ambiguity of what the operation does. It's implicitly "current version >= 
>> specified version", but I wonder how many people will want to compare 
>> otherwise or will assume the comparison is '=='.
>> 
>> We can fix this in two ways:
>> 
>> Option 1: #if swift(> 
>> or
>> 
>> Option 2: #if swift > x.y
>> 
>> I thought I preferred Option 1 but I think Option 2 reads more how you would 
>> expect and somewhat reflects the regular syntax of the language, FWIW. I 
>> sketched out both implementations and they're about the same in complexity, 
>> so I would suggest Option 2, unless it's a strong goal to keep special sauce 
>> in build configurations as "function calls".
>> 
>> Maybe not all of the comparison operators are necessary, but in general this 
>> gives some flexibility to arrange checks (newer code at the top or at the 
>> bottom) and actually describes what comparison is happening.
> 
> I don't like either of these. I especially don't like option 2 because it 
> makes "swift" something magic while user flags are still limited to booleans, 
> and I don't think we're likely to change user flags any time soon. But I 
> don't like option 1 either. We didn't do it for "if #available(…)", and I 
> don't think we need to do it here either.
> 
> Jordan

Are you in favor of the original syntax?

David
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Dirk Schreib via swift-evolution]

> On 20 Dec 2015, at 07:01, Jordan Rose via swift-evolution 
>  wrote:
> 
> 
>> On Dec 19, 2015, at 1:28 , David Farler via swift-evolution 
>>  wrote:
>> 
>> 
 On Dec 18, 2015, at 3:34 PM, Douglas Gregor via swift-evolution 
  wrote:
 
 
> On Dec 18, 2015, at 12:29 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
> 
> On Dec 18, 2015, at 12:25 PM, Radosław Pietruszewski via swift-evolution 
>  wrote:
> 
> Sounds like it could be super useful for libraries!
> 
> How about we drop the quote marks, though? If we have `os(iOS)` and 
> `#available(iOS 9, *)` (in other context), why not `swift(2.2)`?
 
 I agree with Radek.
 
 The argument to use a string is if we wanted to support subversions, e.g. 
 like “#if swift(2.2.1)”.  This requires the parameter to be a string, 
 because 2.2.1 isn’t a valid floating point literal - the lexer will be 
 displeased.
 
 However, I don’t think we *want* the feature to be able to do that.  The 
 most important use case for this feature is to handle syntactic 
 differences across swift versions, and we don’t want those in 
 sub-versions.  Given that, it seems better to keep the syntax clean and 
 simple.
>>> 
>>> This feature LGTM, and I also prefer that we drop the quotes. Two levels of 
>>> version number should be sufficient.
>>> 
>>>- Doug
>> 
>> Chris brought something up that a few of us had discussed in the past: the 
>> ambiguity of what the operation does. It's implicitly "current version >= 
>> specified version", but I wonder how many people will want to compare 
>> otherwise or will assume the comparison is '=='.
>> 
>> We can fix this in two ways:
>> 
>> Option 1: #if swift(> 
>> or
>> 
>> Option 2: #if swift > x.y
>> 
>> I thought I preferred Option 1 but I think Option 2 reads more how you would 
>> expect and somewhat reflects the regular syntax of the language, FWIW. I 
>> sketched out both implementations and they're about the same in complexity, 
>> so I would suggest Option 2, unless it's a strong goal to keep special sauce 
>> in build configurations as "function calls".
>> 
>> Maybe not all of the comparison operators are necessary, but in general this 
>> gives some flexibility to arrange checks (newer code at the top or at the 
>> bottom) and actually describes what comparison is happening.
> 
> I don't like either of these. I especially don't like option 2 because it 
> makes "swift" something magic while user flags are still limited to booleans, 
> and I don't think we're likely to change user flags any time soon. But I 
> don't like option 1 either. We didn't do it for "if #available(…)", and I 
> don't think we need to do it here either.
> 
> Jordan
> 
What about the following syntax?
#if Swift.sinceVersion( 2, minor: 2 )
or even better:
#if Swift.isFeatureAvailable( "foo" )
The look&feel is standard Swift. Just at compile time. In both cases optional 
parameter values are possible. 

- Dirk


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jordan Rose via swift-evolution]

> On Dec 19, 2015, at 1:28 , David Farler via swift-evolution 
>  wrote:
> 
> 
>> On Dec 18, 2015, at 3:34 PM, Douglas Gregor via swift-evolution 
>>  wrote:
>> 
>>> 
>>> On Dec 18, 2015, at 12:29 PM, Chris Lattner via swift-evolution 
>>>  wrote:
>>> 
 
 On Dec 18, 2015, at 12:25 PM, Radosław Pietruszewski via swift-evolution 
  wrote:
 
 Sounds like it could be super useful for libraries!
 
 How about we drop the quote marks, though? If we have `os(iOS)` and 
 `#available(iOS 9, *)` (in other context), why not `swift(2.2)`?
>>> 
>>> I agree with Radek.
>>> 
>>> The argument to use a string is if we wanted to support subversions, e.g. 
>>> like “#if swift(2.2.1)”.  This requires the parameter to be a string, 
>>> because 2.2.1 isn’t a valid floating point literal - the lexer will be 
>>> displeased.
>>> 
>>> However, I don’t think we *want* the feature to be able to do that.  The 
>>> most important use case for this feature is to handle syntactic differences 
>>> across swift versions, and we don’t want those in sub-versions.  Given 
>>> that, it seems better to keep the syntax clean and simple.
>> 
>> This feature LGTM, and I also prefer that we drop the quotes. Two levels of 
>> version number should be sufficient.
>> 
>>  - Doug
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> Chris brought something up that a few of us had discussed in the past: the 
> ambiguity of what the operation does. It's implicitly "current version >= 
> specified version", but I wonder how many people will want to compare 
> otherwise or will assume the comparison is '=='.
> 
> We can fix this in two ways:
> 
> Option 1: #if swift( 
> or
> 
> Option 2: #if swift > x.y
> 
> I thought I preferred Option 1 but I think Option 2 reads more how you would 
> expect and somewhat reflects the regular syntax of the language, FWIW. I 
> sketched out both implementations and they're about the same in complexity, 
> so I would suggest Option 2, unless it's a strong goal to keep special sauce 
> in build configurations as "function calls".
> 
> Maybe not all of the comparison operators are necessary, but in general this 
> gives some flexibility to arrange checks (newer code at the top or at the 
> bottom) and actually describes what comparison is happening.

I don't like either of these. I especially don't like option 2 because it makes 
"swift" something magic while user flags are still limited to booleans, and I 
don't think we're likely to change user flags any time soon. But I don't like 
option 1 either. We didn't do it for "if #available(…)", and I don't think we 
need to do it here either.

Jordan


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[David Farler via swift-evolution]

Yes, I see your point in that. It might be worth revisiting that for all of the 
build configs in the future. 

David

> On Dec 19, 2015, at 15:51, Félix Cloutier  wrote:
> 
> It's not surprising that what's inside an #if swift block isn't compiled, but 
> since it doesn't, it might be surprising that what is inside an #if DEBUG 
> block is compiled, no?
> 
>> Le 19 déc. 2015 à 17:58:35, David Farler  a écrit :
>> 
>> I don't know if I would say it violates the principle of least surprise 
>> because it wouldn't actually be a surprise in this case, since it's the 
>> whole reason you would choose to use `#if swift` – to ignore irrelevant 
>> syntax errors.
>> 
>> The difference is also smaller than you might think. The #else branches in 
>> the other build configurations parse because presumably the language's 
>> syntax wouldn't change between operating systems or architectures, however 
>> they never go through type checking or semantic analysis. For example:
>> 
>> cat -n test.swift
>> 
>> 1  #if os(iOS)
>> 2print("Hello")
>> 3  #else
>> 4print("Hello")
>> 5  #endif
>> 
>> Compiling for OS X, both branches are valid Swift and would actually type 
>> check fine, but:
>> 
>> xcrun -sdk macosx swiftc -dump-ast test.swift
>> 
>> (source_file
>> (top_level_code_decl
>>   (brace_stmt
>> (#if_stmt
>>   (#if:
>> (call_expr type=''
>> 
>> ...snip -- all null types up to here.
>> 
>>   #else
>> (elements
>>   (top_level_code_decl
>> (brace_stmt
>>   (call_expr type='()'
>> 
>> ...snip -- all typed up to here.
>> 
>> So, maybe we should revisit the other build configurations in the future, 
>> that it's maybe not worth it to even parse any inactive branches, but I 
>> don't think the difference is so strong that we shouldn't reuse the #if 
>> syntax for this now.
>> 
>> David
>> 
>>> On Dec 19, 2015, at 2:17 PM, Félix Cloutier  wrote:
>>> 
>>> I don't really like how different this makes "#if swift" from "#if 
>>> ". To me, that would be a violation of the principle of 
>>> least astonishment.
>>> 
 Le 19 déc. 2015 à 17:08:13, David Farler via swift-evolution 
  a écrit :
 
 
 
>> On Dec 19, 2015, at 13:48, Michel Fortin  
>> wrote:
>> 
>> Le 18 déc. 2015 à 15:22, David Farler via swift-evolution 
>>  a écrit :
>> 
>> #if swift("2.2")
>> print("Hello")
>> #else
>> this code will not parse or emit diagnostics
>> #endif
> 
> This is a change from how the #if directive currently works. Currently, 
> it's a syntax error to write this:
> 
> #if DEBUG
> @abaraka func test() {}
> #endif
> 
> even if DEBUG is false because the content is parsed regardless and 
> @abaraka is not a valid attribute. The syntax inside the #if/#endif must 
> be valid for the parser.
> 
> So this proposal implies a change in how #if is parsed. Should it works 
> like the C preprocessor?
> 
> -- 
> Michel Fortin
> michel.fortin@michel
 
 Yes, that's right, it is a change but only for this new directive because 
 one of its uses is to control exposure to syntax or API changes. Other 
 build configurations such as 'os' and 'arch' will be unaffected. 
 
 I myself wouldn't want build configs to act like the C preprocessor, 
 although that kind of change is probably out of this proposal's scope 
 anyway, IMO.
 
 David
 ___
 swift-evolution mailing list
 swift-evolution@swift.org
 https://lists.swift.org/mailman/listinfo/swift-evolution
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Félix Cloutier via swift-evolution]

It's not surprising that what's inside an #if swift block isn't compiled, but 
since it doesn't, it might be surprising that what is inside an #if DEBUG block 
is compiled, no?

> Le 19 déc. 2015 à 17:58:35, David Farler  a écrit :
> 
> I don't know if I would say it violates the principle of least surprise 
> because it wouldn't actually be a surprise in this case, since it's the whole 
> reason you would choose to use `#if swift` – to ignore irrelevant syntax 
> errors.
> 
> The difference is also smaller than you might think. The #else branches in 
> the other build configurations parse because presumably the language's syntax 
> wouldn't change between operating systems or architectures, however they 
> never go through type checking or semantic analysis. For example:
> 
> cat -n test.swift
> 
> 1  #if os(iOS)
> 2print("Hello")
> 3  #else
> 4print("Hello")
> 5  #endif
> 
> Compiling for OS X, both branches are valid Swift and would actually type 
> check fine, but:
> 
> xcrun -sdk macosx swiftc -dump-ast test.swift
> 
> (source_file
>  (top_level_code_decl
>(brace_stmt
>  (#if_stmt
>(#if:
>  (call_expr type=''
> 
> ...snip -- all null types up to here.
> 
>#else
>  (elements
>(top_level_code_decl
>  (brace_stmt
>(call_expr type='()'
> 
> ...snip -- all typed up to here.
> 
> So, maybe we should revisit the other build configurations in the future, 
> that it's maybe not worth it to even parse any inactive branches, but I don't 
> think the difference is so strong that we shouldn't reuse the #if syntax for 
> this now.
> 
> David
> 
>> On Dec 19, 2015, at 2:17 PM, Félix Cloutier  wrote:
>> 
>> I don't really like how different this makes "#if swift" from "#if > else>". To me, that would be a violation of the principle of least 
>> astonishment.
>> 
>>> Le 19 déc. 2015 à 17:08:13, David Farler via swift-evolution 
>>>  a écrit :
>>> 
>>> 
>>> 
 On Dec 19, 2015, at 13:48, Michel Fortin  wrote:
 
> Le 18 déc. 2015 à 15:22, David Farler via swift-evolution 
>  a écrit :
> 
> #if swift("2.2")
> print("Hello")
> #else
> this code will not parse or emit diagnostics
> #endif
 
 This is a change from how the #if directive currently works. Currently, 
 it's a syntax error to write this:
 
  #if DEBUG
  @abaraka func test() {}
  #endif
 
 even if DEBUG is false because the content is parsed regardless and 
 @abaraka is not a valid attribute. The syntax inside the #if/#endif must 
 be valid for the parser.
 
 So this proposal implies a change in how #if is parsed. Should it works 
 like the C preprocessor?
 
 -- 
 Michel Fortin
 michel.fortin@michel
>>> 
>>> Yes, that's right, it is a change but only for this new directive because 
>>> one of its uses is to control exposure to syntax or API changes. Other 
>>> build configurations such as 'os' and 'arch' will be unaffected. 
>>> 
>>> I myself wouldn't want build configs to act like the C preprocessor, 
>>> although that kind of change is probably out of this proposal's scope 
>>> anyway, IMO.
>>> 
>>> David
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[David Farler via swift-evolution]

I don't know if I would say it violates the principle of least surprise because 
it wouldn't actually be a surprise in this case, since it's the whole reason 
you would choose to use `#if swift` – to ignore irrelevant syntax errors.

The difference is also smaller than you might think. The #else branches in the 
other build configurations parse because presumably the language's syntax 
wouldn't change between operating systems or architectures, however they never 
go through type checking or semantic analysis. For example:

cat -n test.swift

1  #if os(iOS)
2print("Hello")
3  #else
4print("Hello")
5  #endif

Compiling for OS X, both branches are valid Swift and would actually type check 
fine, but:

xcrun -sdk macosx swiftc -dump-ast test.swift

(source_file
  (top_level_code_decl
(brace_stmt
  (#if_stmt
(#if:
  (call_expr type=''

...snip -- all null types up to here.

#else
  (elements
(top_level_code_decl
  (brace_stmt
(call_expr type='()'

...snip -- all typed up to here.

So, maybe we should revisit the other build configurations in the future, that 
it's maybe not worth it to even parse any inactive branches, but I don't think 
the difference is so strong that we shouldn't reuse the #if syntax for this now.

David

> On Dec 19, 2015, at 2:17 PM, Félix Cloutier  wrote:
> 
> I don't really like how different this makes "#if swift" from "#if  else>". To me, that would be a violation of the principle of least 
> astonishment.
> 
>> Le 19 déc. 2015 à 17:08:13, David Farler via swift-evolution 
>>  a écrit :
>> 
>> 
>> 
>>> On Dec 19, 2015, at 13:48, Michel Fortin  wrote:
>>> 
 Le 18 déc. 2015 à 15:22, David Farler via swift-evolution 
  a écrit :
 
 #if swift("2.2")
 print("Hello")
 #else
 this code will not parse or emit diagnostics
 #endif
>>> 
>>> This is a change from how the #if directive currently works. Currently, 
>>> it's a syntax error to write this:
>>> 
>>>   #if DEBUG
>>>   @abaraka func test() {}
>>>   #endif
>>> 
>>> even if DEBUG is false because the content is parsed regardless and 
>>> @abaraka is not a valid attribute. The syntax inside the #if/#endif must be 
>>> valid for the parser.
>>> 
>>> So this proposal implies a change in how #if is parsed. Should it works 
>>> like the C preprocessor?
>>> 
>>> -- 
>>> Michel Fortin
>>> michel.fortin@michel
>> 
>> Yes, that's right, it is a change but only for this new directive because 
>> one of its uses is to control exposure to syntax or API changes. Other build 
>> configurations such as 'os' and 'arch' will be unaffected. 
>> 
>> I myself wouldn't want build configs to act like the C preprocessor, 
>> although that kind of change is probably out of this proposal's scope 
>> anyway, IMO.
>> 
>> David
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Félix Cloutier via swift-evolution]

I don't really like how different this makes "#if swift" from "#if ". To me, that would be a violation of the principle of least astonishment.

> Le 19 déc. 2015 à 17:08:13, David Farler via swift-evolution 
>  a écrit :
> 
> 
> 
>> On Dec 19, 2015, at 13:48, Michel Fortin  wrote:
>> 
>>> Le 18 déc. 2015 à 15:22, David Farler via swift-evolution 
>>>  a écrit :
>>> 
>>> #if swift("2.2")
>>> print("Hello")
>>> #else
>>> this code will not parse or emit diagnostics
>>> #endif
>> 
>> This is a change from how the #if directive currently works. Currently, it's 
>> a syntax error to write this:
>> 
>>   #if DEBUG
>>   @abaraka func test() {}
>>   #endif
>> 
>> even if DEBUG is false because the content is parsed regardless and @abaraka 
>> is not a valid attribute. The syntax inside the #if/#endif must be valid for 
>> the parser.
>> 
>> So this proposal implies a change in how #if is parsed. Should it works like 
>> the C preprocessor?
>> 
>> -- 
>> Michel Fortin
>> michel.fortin@michel
> 
> Yes, that's right, it is a change but only for this new directive because one 
> of its uses is to control exposure to syntax or API changes. Other build 
> configurations such as 'os' and 'arch' will be unaffected. 
> 
> I myself wouldn't want build configs to act like the C preprocessor, although 
> that kind of change is probably out of this proposal's scope anyway, IMO.
> 
> David
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[David Farler via swift-evolution]

> On Dec 19, 2015, at 13:48, Michel Fortin  wrote:
> 
>> Le 18 déc. 2015 à 15:22, David Farler via swift-evolution 
>>  a écrit :
>> 
>> #if swift("2.2")
>> print("Hello")
>> #else
>> this code will not parse or emit diagnostics
>> #endif
> 
> This is a change from how the #if directive currently works. Currently, it's 
> a syntax error to write this:
> 
>#if DEBUG
>@abaraka func test() {}
>#endif
> 
> even if DEBUG is false because the content is parsed regardless and @abaraka 
> is not a valid attribute. The syntax inside the #if/#endif must be valid for 
> the parser.
> 
> So this proposal implies a change in how #if is parsed. Should it works like 
> the C preprocessor?
> 
> -- 
> Michel Fortin
> michel.fortin@michel

Yes, that's right, it is a change but only for this new directive because one 
of its uses is to control exposure to syntax or API changes. Other build 
configurations such as 'os' and 'arch' will be unaffected. 

I myself wouldn't want build configs to act like the C preprocessor, although 
that kind of change is probably out of this proposal's scope anyway, IMO.

David
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Dave Abrahams via swift-evolution]

> On Dec 19, 2015, at 1:26 PM, Félix Cloutier via swift-evolution 
>  wrote:
> 
> That's not how I read it. The stable ABI point says (emphasis mine):
> 
>> Stabilize the binary interface (ABI) to guarantee a level of binary 
>> compatibility moving forward. This involves finalizing runtime data 
>> structures, name mangling, calling conventions, and so on, as well as 
>> finalizing some of the details of the language itself that have an impact on 
>> its ABI. **Stabilizing the ABI also extends to the Standard Library, its 
>> data types, and core algorithms.** Successful ABI stabilization means that 
>> applications and libraries compiled with future versions of Swift can 
>> interact at a binary level with applications and libraries compiled with 
>> Swift 3.0, even if the source language changes.
> 
> If Swift 3 succeeds with this goal, there can be new interfaces in the 
> standard library, but existing interfaces will be final.

Basically correct, though changes are possible to existing interfaces after a 
long period of deprecation.

> My experience with other languages is that even when it's possible to 
> determine if the compiler/library supports some feature, unless you're a 
> Boost maintainer, people tend to target one version of the language anyway, 
> either the older one using a workaround portable to the newer version, or the 
> new version without regards to people stuck behind.
> 
> The one notable exception I can think of is Python 2 vs Python 3, but that's 
> because the "ABI" underwent very important changes.
> 
> That's why I'm asking what it would be used for.
> 
>> Le 19 déc. 2015 à 15:52:08, Ludovic LANDRY > > a écrit :
>> 
>> @felix Swift 3 will stabilize ABI (binary level compatibility) but not the 
>> standard library interfaces (cf. https://github.com/apple/swift-evolution 
>>  > Out of Scope > Full source 
>> compatibility). 
>> 
>> Even is they are stabilized in the future, there can still be some API added 
>> in future Swift versions.
>> 
>> 
>> On Sat, Dec 19, 2015 at 12:26 PM, Félix Cloutier > > wrote:
>> My understanding is that Swift 3 will stabilize the ABI and the standard 
>> library interfaces. Given that, I'm not sure what you'd use it for either.
>> 
>>> Le 19 déc. 2015 à 14:26:24, Javier Soto via swift-evolution 
>>> mailto:swift-evolution@swift.org>> a écrit :
>>> 
>>> What's the intended most common use case for this? The one that I can think 
>>> of that will show up very often is "declare this function only if Swift 
>>> version is >= X because it relies on some new feature"
>>> In that case, would it make sense for consistency to also be able to mark a 
>>> function (or type) as "only available on Swift >= X", like you do with ios 
>>> releases? (ie @available(swift, 2.2))
>>> On Sat, Dec 19, 2015 at 1:28 AM David Farler via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> > On Dec 18, 2015, at 3:34 PM, Douglas Gregor via swift-evolution 
>>> > mailto:swift-evolution@swift.org>> wrote:
>>> >
>>> >>
>>> >> On Dec 18, 2015, at 12:29 PM, Chris Lattner via swift-evolution 
>>> >> mailto:swift-evolution@swift.org>> wrote:
>>> >>
>>> >>>
>>> >>> On Dec 18, 2015, at 12:25 PM, Radosław Pietruszewski via 
>>> >>> swift-evolution >> >>> > wrote:
>>> >>>
>>> >>> Sounds like it could be super useful for libraries!
>>> >>>
>>> >>> How about we drop the quote marks, though? If we have `os(iOS)` and 
>>> >>> `#available(iOS 9, *)` (in other context), why not `swift(2.2)`?
>>> >>
>>> >> I agree with Radek.
>>> >>
>>> >> The argument to use a string is if we wanted to support subversions, 
>>> >> e.g. like “#if swift(2.2.1)”.  This requires the parameter to be a 
>>> >> string, because 2.2.1 isn’t a valid floating point literal - the lexer 
>>> >> will be displeased.
>>> >>
>>> >> However, I don’t think we *want* the feature to be able to do that.  The 
>>> >> most important use case for this feature is to handle syntactic 
>>> >> differences across swift versions, and we don’t want those in 
>>> >> sub-versions.  Given that, it seems better to keep the syntax clean and 
>>> >> simple.
>>> >
>>> > This feature LGTM, and I also prefer that we drop the quotes. Two levels 
>>> > of version number should be sufficient.
>>> >
>>> >   - Doug
>>> >
>>> >  ___
>>> > swift-evolution mailing list
>>> > swift-evolution@swift.org 
>>> > https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> > 
>>> 
>>> Chris brought something up that a few of us had discussed in the past: the 
>>> ambiguity of what the operation does. It's implicitly "current version >= 
>>> specified version", but I wonder how many people will want to compare 
>>> otherwise or will assume the comparison is '=='.

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

[David Farler via swift-evolution]

That is a fair point of comparison, although this should work for both 
statements and declarations, in which case the extra attribute style would be 
redundant.  Maybe the implicit >= is good enough. I'd like to keep it as simple 
as possible. 

David

> On Dec 19, 2015, at 11:26, Javier Soto  wrote:
> 
> What's the intended most common use case for this? The one that I can think 
> of that will show up very often is "declare this function only if Swift 
> version is >= X because it relies on some new feature"
> In that case, would it make sense for consistency to also be able to mark a 
> function (or type) as "only available on Swift >= X", like you do with ios 
> releases? (ie @available(swift, 2.2))
>> On Sat, Dec 19, 2015 at 1:28 AM David Farler via swift-evolution 
>>  wrote:
>> 
>> > On Dec 18, 2015, at 3:34 PM, Douglas Gregor via swift-evolution 
>> >  wrote:
>> >
>> >>
>> >> On Dec 18, 2015, at 12:29 PM, Chris Lattner via swift-evolution 
>> >>  wrote:
>> >>
>> >>>
>> >>> On Dec 18, 2015, at 12:25 PM, Radosław Pietruszewski via swift-evolution 
>> >>>  wrote:
>> >>>
>> >>> Sounds like it could be super useful for libraries!
>> >>>
>> >>> How about we drop the quote marks, though? If we have `os(iOS)` and 
>> >>> `#available(iOS 9, *)` (in other context), why not `swift(2.2)`?
>> >>
>> >> I agree with Radek.
>> >>
>> >> The argument to use a string is if we wanted to support subversions, e.g. 
>> >> like “#if swift(2.2.1)”.  This requires the parameter to be a string, 
>> >> because 2.2.1 isn’t a valid floating point literal - the lexer will be 
>> >> displeased.
>> >>
>> >> However, I don’t think we *want* the feature to be able to do that.  The 
>> >> most important use case for this feature is to handle syntactic 
>> >> differences across swift versions, and we don’t want those in 
>> >> sub-versions.  Given that, it seems better to keep the syntax clean and 
>> >> simple.
>> >
>> > This feature LGTM, and I also prefer that we drop the quotes. Two levels 
>> > of version number should be sufficient.
>> >
>> >   - Doug
>> >
>> >  ___
>> > swift-evolution mailing list
>> > swift-evolution@swift.org
>> > https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> Chris brought something up that a few of us had discussed in the past: the 
>> ambiguity of what the operation does. It's implicitly "current version >= 
>> specified version", but I wonder how many people will want to compare 
>> otherwise or will assume the comparison is '=='.
>> 
>> We can fix this in two ways:
>> 
>> Option 1: #if swift(> 
>> or
>> 
>> Option 2: #if swift > x.y
>> 
>> I thought I preferred Option 1 but I think Option 2 reads more how you would 
>> expect and somewhat reflects the regular syntax of the language, FWIW. I 
>> sketched out both implementations and they're about the same in complexity, 
>> so I would suggest Option 2, unless it's a strong goal to keep special sauce 
>> in build configurations as "function calls".
>> 
>> Maybe not all of the comparison operators are necessary, but in general this 
>> gives some flexibility to arrange checks (newer code at the top or at the 
>> bottom) and actually describes what comparison is happening.
>> 
>> David
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> -- 
> Javier Soto
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Michel Fortin via swift-evolution]

Le 18 déc. 2015 à 15:22, David Farler via swift-evolution 
 a écrit :

> #if swift("2.2")
>  print("Hello")
> #else
>  this code will not parse or emit diagnostics
> #endif

This is a change from how the #if directive currently works. Currently, it's a 
syntax error to write this:

#if DEBUG
@abaraka func test() {}
#endif

even if DEBUG is false because the content is parsed regardless and @abaraka is 
not a valid attribute. The syntax inside the #if/#endif must be valid for the 
parser.

So this proposal implies a change in how #if is parsed. Should it works like 
the C preprocessor?

-- 
Michel Fortin
michel.for...@michelf.ca
https://michelf.ca

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Félix Cloutier via swift-evolution]

That's not how I read it. The stable ABI point says (emphasis mine):

> Stabilize the binary interface (ABI) to guarantee a level of binary 
> compatibility moving forward. This involves finalizing runtime data 
> structures, name mangling, calling conventions, and so on, as well as 
> finalizing some of the details of the language itself that have an impact on 
> its ABI. **Stabilizing the ABI also extends to the Standard Library, its data 
> types, and core algorithms.** Successful ABI stabilization means that 
> applications and libraries compiled with future versions of Swift can 
> interact at a binary level with applications and libraries compiled with 
> Swift 3.0, even if the source language changes.

If Swift 3 succeeds with this goal, there can be new interfaces in the standard 
library, but existing interfaces will be final.

My experience with other languages is that even when it's possible to determine 
if the compiler/library supports some feature, unless you're a Boost 
maintainer, people tend to target one version of the language anyway, either 
the older one using a workaround portable to the newer version, or the new 
version without regards to people stuck behind.

The one notable exception I can think of is Python 2 vs Python 3, but that's 
because the "ABI" underwent very important changes.

That's why I'm asking what it would be used for.

> Le 19 déc. 2015 à 15:52:08, Ludovic LANDRY  a écrit :
> 
> @felix Swift 3 will stabilize ABI (binary level compatibility) but not the 
> standard library interfaces (cf. https://github.com/apple/swift-evolution 
>  > Out of Scope > Full source 
> compatibility). 
> 
> Even is they are stabilized in the future, there can still be some API added 
> in future Swift versions.
> 
> 
> On Sat, Dec 19, 2015 at 12:26 PM, Félix Cloutier  > wrote:
> My understanding is that Swift 3 will stabilize the ABI and the standard 
> library interfaces. Given that, I'm not sure what you'd use it for either.
> 
>> Le 19 déc. 2015 à 14:26:24, Javier Soto via swift-evolution 
>> mailto:swift-evolution@swift.org>> a écrit :
>> 
>> What's the intended most common use case for this? The one that I can think 
>> of that will show up very often is "declare this function only if Swift 
>> version is >= X because it relies on some new feature"
>> In that case, would it make sense for consistency to also be able to mark a 
>> function (or type) as "only available on Swift >= X", like you do with ios 
>> releases? (ie @available(swift, 2.2))
>> On Sat, Dec 19, 2015 at 1:28 AM David Farler via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> > On Dec 18, 2015, at 3:34 PM, Douglas Gregor via swift-evolution 
>> > mailto:swift-evolution@swift.org>> wrote:
>> >
>> >>
>> >> On Dec 18, 2015, at 12:29 PM, Chris Lattner via swift-evolution 
>> >> mailto:swift-evolution@swift.org>> wrote:
>> >>
>> >>>
>> >>> On Dec 18, 2015, at 12:25 PM, Radosław Pietruszewski via swift-evolution 
>> >>> mailto:swift-evolution@swift.org>> wrote:
>> >>>
>> >>> Sounds like it could be super useful for libraries!
>> >>>
>> >>> How about we drop the quote marks, though? If we have `os(iOS)` and 
>> >>> `#available(iOS 9, *)` (in other context), why not `swift(2.2)`?
>> >>
>> >> I agree with Radek.
>> >>
>> >> The argument to use a string is if we wanted to support subversions, e.g. 
>> >> like “#if swift(2.2.1)”.  This requires the parameter to be a string, 
>> >> because 2.2.1 isn’t a valid floating point literal - the lexer will be 
>> >> displeased.
>> >>
>> >> However, I don’t think we *want* the feature to be able to do that.  The 
>> >> most important use case for this feature is to handle syntactic 
>> >> differences across swift versions, and we don’t want those in 
>> >> sub-versions.  Given that, it seems better to keep the syntax clean and 
>> >> simple.
>> >
>> > This feature LGTM, and I also prefer that we drop the quotes. Two levels 
>> > of version number should be sufficient.
>> >
>> >   - Doug
>> >
>> >  ___
>> > swift-evolution mailing list
>> > swift-evolution@swift.org 
>> > https://lists.swift.org/mailman/listinfo/swift-evolution 
>> > 
>> 
>> Chris brought something up that a few of us had discussed in the past: the 
>> ambiguity of what the operation does. It's implicitly "current version >= 
>> specified version", but I wonder how many people will want to compare 
>> otherwise or will assume the comparison is '=='.
>> 
>> We can fix this in two ways:
>> 
>> Option 1: #if swift(> 
>> or
>> 
>> Option 2: #if swift > x.y
>> 
>> I thought I preferred Option 1 but I think Option 2 reads more how you would 
>> expect and somewhat reflects the regular syntax of the language, FWIW. I 
>> sketched out both implementations and they're about the same in complexity

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

[Ludovic LANDRY via swift-evolution]

@felix Swift 3 will stabilize ABI (binary level compatibility) but not the
standard library interfaces (cf. https://github.com/apple/swift-evolution >
Out of Scope > Full source compatibility).

Even is they are stabilized in the future, there can still be some API
added in future Swift versions.


On Sat, Dec 19, 2015 at 12:26 PM, Félix Cloutier 
wrote:

> My understanding is that Swift 3 will stabilize the ABI and the standard
> library interfaces. Given that, I'm not sure what you'd use it for either.
>
> Le 19 déc. 2015 à 14:26:24, Javier Soto via swift-evolution <
> swift-evolution@swift.org> a écrit :
>
> What's the intended most common use case for this? The one that I can
> think of that will show up very often is "declare this function only if
> Swift version is >= X because it relies on some new feature"
> In that case, would it make sense for consistency to also be able to mark
> a function (or type) as "only available on Swift >= X", like you do with
> ios releases? (ie @available(swift, 2.2))
> On Sat, Dec 19, 2015 at 1:28 AM David Farler via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>>
>> > On Dec 18, 2015, at 3:34 PM, Douglas Gregor via swift-evolution <
>> swift-evolution@swift.org> wrote:
>> >
>> >>
>> >> On Dec 18, 2015, at 12:29 PM, Chris Lattner via swift-evolution <
>> swift-evolution@swift.org> wrote:
>> >>
>> >>>
>> >>> On Dec 18, 2015, at 12:25 PM, Radosław Pietruszewski via
>> swift-evolution  wrote:
>> >>>
>> >>> Sounds like it could be super useful for libraries!
>> >>>
>> >>> How about we drop the quote marks, though? If we have `os(iOS)` and
>> `#available(iOS 9, *)` (in other context), why not `swift(2.2)`?
>> >>
>> >> I agree with Radek.
>> >>
>> >> The argument to use a string is if we wanted to support subversions,
>> e.g. like “#if swift(2.2.1)”.  This requires the parameter to be a string,
>> because 2.2.1 isn’t a valid floating point literal - the lexer will be
>> displeased.
>> >>
>> >> However, I don’t think we *want* the feature to be able to do that.
>> The most important use case for this feature is to handle syntactic
>> differences across swift versions, and we don’t want those in
>> sub-versions.  Given that, it seems better to keep the syntax clean and
>> simple.
>> >
>> > This feature LGTM, and I also prefer that we drop the quotes. Two
>> levels of version number should be sufficient.
>> >
>> >   - Doug
>> >
>> >  ___
>> > swift-evolution mailing list
>> > swift-evolution@swift.org
>> > https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>> Chris brought something up that a few of us had discussed in the past:
>> the ambiguity of what the operation does. It's implicitly "current version
>> >= specified version", but I wonder how many people will want to compare
>> otherwise or will assume the comparison is '=='.
>>
>> We can fix this in two ways:
>>
>> Option 1: #if swift(>
>> or
>>
>> Option 2: #if swift > x.y
>>
>> I thought I preferred Option 1 but I think Option 2 reads more how you
>> would expect and somewhat reflects the regular syntax of the language,
>> FWIW. I sketched out both implementations and they're about the same in
>> complexity, so I would suggest Option 2, unless it's a strong goal to keep
>> special sauce in build configurations as "function calls".
>>
>> Maybe not all of the comparison operators are necessary, but in general
>> this gives some flexibility to arrange checks (newer code at the top or at
>> the bottom) and actually describes what comparison is happening.
>>
>> David
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
> --
> Javier Soto ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>


-- 
Cordialement,
Ludovic Landry
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Félix Cloutier via swift-evolution]

My understanding is that Swift 3 will stabilize the ABI and the standard 
library interfaces. Given that, I'm not sure what you'd use it for either.

> Le 19 déc. 2015 à 14:26:24, Javier Soto via swift-evolution 
>  a écrit :
> 
> What's the intended most common use case for this? The one that I can think 
> of that will show up very often is "declare this function only if Swift 
> version is >= X because it relies on some new feature"
> In that case, would it make sense for consistency to also be able to mark a 
> function (or type) as "only available on Swift >= X", like you do with ios 
> releases? (ie @available(swift, 2.2))
> On Sat, Dec 19, 2015 at 1:28 AM David Farler via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> 
> > On Dec 18, 2015, at 3:34 PM, Douglas Gregor via swift-evolution 
> > mailto:swift-evolution@swift.org>> wrote:
> >
> >>
> >> On Dec 18, 2015, at 12:29 PM, Chris Lattner via swift-evolution 
> >> mailto:swift-evolution@swift.org>> wrote:
> >>
> >>>
> >>> On Dec 18, 2015, at 12:25 PM, Radosław Pietruszewski via swift-evolution 
> >>> mailto:swift-evolution@swift.org>> wrote:
> >>>
> >>> Sounds like it could be super useful for libraries!
> >>>
> >>> How about we drop the quote marks, though? If we have `os(iOS)` and 
> >>> `#available(iOS 9, *)` (in other context), why not `swift(2.2)`?
> >>
> >> I agree with Radek.
> >>
> >> The argument to use a string is if we wanted to support subversions, e.g. 
> >> like “#if swift(2.2.1)”.  This requires the parameter to be a string, 
> >> because 2.2.1 isn’t a valid floating point literal - the lexer will be 
> >> displeased.
> >>
> >> However, I don’t think we *want* the feature to be able to do that.  The 
> >> most important use case for this feature is to handle syntactic 
> >> differences across swift versions, and we don’t want those in 
> >> sub-versions.  Given that, it seems better to keep the syntax clean and 
> >> simple.
> >
> > This feature LGTM, and I also prefer that we drop the quotes. Two levels of 
> > version number should be sufficient.
> >
> >   - Doug
> >
> >  ___
> > swift-evolution mailing list
> > swift-evolution@swift.org 
> > https://lists.swift.org/mailman/listinfo/swift-evolution 
> > 
> 
> Chris brought something up that a few of us had discussed in the past: the 
> ambiguity of what the operation does. It's implicitly "current version >= 
> specified version", but I wonder how many people will want to compare 
> otherwise or will assume the comparison is '=='.
> 
> We can fix this in two ways:
> 
> Option 1: #if swift( 
> or
> 
> Option 2: #if swift > x.y
> 
> I thought I preferred Option 1 but I think Option 2 reads more how you would 
> expect and somewhat reflects the regular syntax of the language, FWIW. I 
> sketched out both implementations and they're about the same in complexity, 
> so I would suggest Option 2, unless it's a strong goal to keep special sauce 
> in build configurations as "function calls".
> 
> Maybe not all of the comparison operators are necessary, but in general this 
> gives some flexibility to arrange checks (newer code at the top or at the 
> bottom) and actually describes what comparison is happening.
> 
> David
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> -- 
> Javier Soto  ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Javier Soto via swift-evolution]

What's the intended most common use case for this? The one that I can think
of that will show up very often is "declare this function only if Swift
version is >= X because it relies on some new feature"
In that case, would it make sense for consistency to also be able to mark a
function (or type) as "only available on Swift >= X", like you do with ios
releases? (ie @available(swift, 2.2))
On Sat, Dec 19, 2015 at 1:28 AM David Farler via swift-evolution <
swift-evolution@swift.org> wrote:

>
> > On Dec 18, 2015, at 3:34 PM, Douglas Gregor via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> >>
> >> On Dec 18, 2015, at 12:29 PM, Chris Lattner via swift-evolution <
> swift-evolution@swift.org> wrote:
> >>
> >>>
> >>> On Dec 18, 2015, at 12:25 PM, Radosław Pietruszewski via
> swift-evolution  wrote:
> >>>
> >>> Sounds like it could be super useful for libraries!
> >>>
> >>> How about we drop the quote marks, though? If we have `os(iOS)` and
> `#available(iOS 9, *)` (in other context), why not `swift(2.2)`?
> >>
> >> I agree with Radek.
> >>
> >> The argument to use a string is if we wanted to support subversions,
> e.g. like “#if swift(2.2.1)”.  This requires the parameter to be a string,
> because 2.2.1 isn’t a valid floating point literal - the lexer will be
> displeased.
> >>
> >> However, I don’t think we *want* the feature to be able to do that.
> The most important use case for this feature is to handle syntactic
> differences across swift versions, and we don’t want those in
> sub-versions.  Given that, it seems better to keep the syntax clean and
> simple.
> >
> > This feature LGTM, and I also prefer that we drop the quotes. Two levels
> of version number should be sufficient.
> >
> >   - Doug
> >
> >  ___
> > swift-evolution mailing list
> > swift-evolution@swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
> Chris brought something up that a few of us had discussed in the past: the
> ambiguity of what the operation does. It's implicitly "current version >=
> specified version", but I wonder how many people will want to compare
> otherwise or will assume the comparison is '=='.
>
> We can fix this in two ways:
>
> Option 1: #if swift(
> or
>
> Option 2: #if swift > x.y
>
> I thought I preferred Option 1 but I think Option 2 reads more how you
> would expect and somewhat reflects the regular syntax of the language,
> FWIW. I sketched out both implementations and they're about the same in
> complexity, so I would suggest Option 2, unless it's a strong goal to keep
> special sauce in build configurations as "function calls".
>
> Maybe not all of the comparison operators are necessary, but in general
> this gives some flexibility to arrange checks (newer code at the top or at
> the bottom) and actually describes what comparison is happening.
>
> David
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-- 
Javier Soto
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[David Farler via swift-evolution]

> On Dec 18, 2015, at 3:34 PM, Douglas Gregor via swift-evolution 
>  wrote:
> 
>> 
>> On Dec 18, 2015, at 12:29 PM, Chris Lattner via swift-evolution 
>>  wrote:
>> 
>>> 
>>> On Dec 18, 2015, at 12:25 PM, Radosław Pietruszewski via swift-evolution 
>>>  wrote:
>>> 
>>> Sounds like it could be super useful for libraries!
>>> 
>>> How about we drop the quote marks, though? If we have `os(iOS)` and 
>>> `#available(iOS 9, *)` (in other context), why not `swift(2.2)`?
>> 
>> I agree with Radek.
>> 
>> The argument to use a string is if we wanted to support subversions, e.g. 
>> like “#if swift(2.2.1)”.  This requires the parameter to be a string, 
>> because 2.2.1 isn’t a valid floating point literal - the lexer will be 
>> displeased.
>> 
>> However, I don’t think we *want* the feature to be able to do that.  The 
>> most important use case for this feature is to handle syntactic differences 
>> across swift versions, and we don’t want those in sub-versions.  Given that, 
>> it seems better to keep the syntax clean and simple.
> 
> This feature LGTM, and I also prefer that we drop the quotes. Two levels of 
> version number should be sufficient.
> 
>   - Doug
> 
>  ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

Chris brought something up that a few of us had discussed in the past: the 
ambiguity of what the operation does. It's implicitly "current version >= 
specified version", but I wonder how many people will want to compare otherwise 
or will assume the comparison is '=='.

We can fix this in two ways:

Option 1: #if swift( x.y

I thought I preferred Option 1 but I think Option 2 reads more how you would 
expect and somewhat reflects the regular syntax of the language, FWIW. I 
sketched out both implementations and they're about the same in complexity, so 
I would suggest Option 2, unless it's a strong goal to keep special sauce in 
build configurations as "function calls".

Maybe not all of the comparison operators are necessary, but in general this 
gives some flexibility to arrange checks (newer code at the top or at the 
bottom) and actually describes what comparison is happening.

David
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Douglas Gregor via swift-evolution]

> On Dec 18, 2015, at 12:29 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
>> 
>> On Dec 18, 2015, at 12:25 PM, Radosław Pietruszewski via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> Sounds like it could be super useful for libraries!
>> 
>> How about we drop the quote marks, though? If we have `os(iOS)` and 
>> `#available(iOS 9, *)` (in other context), why not `swift(2.2)`?
> 
> I agree with Radek.
> 
> The argument to use a string is if we wanted to support subversions, e.g. 
> like “#if swift(2.2.1)”.  This requires the parameter to be a string, because 
> 2.2.1 isn’t a valid floating point literal - the lexer will be displeased.
> 
> However, I don’t think we *want* the feature to be able to do that.  The most 
> important use case for this feature is to handle syntactic differences across 
> swift versions, and we don’t want those in sub-versions.  Given that, it 
> seems better to keep the syntax clean and simple.


This feature LGTM, and I also prefer that we drop the quotes. Two levels of 
version number should be sufficient.

- Doug

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[David Farler via swift-evolution]

A bare 2.2 will work. Right now, 2.2.2 won't lex because of a requirement that 
member access of a numeric literal be named but, if we decide down the road 
that we really, really need another version component, it wouldn't be a ton of 
work to give an exception when parsing an #if config.

David

> On Dec 18, 2015, at 1:09 PM, Radosław Pietruszewski  wrote:
> 
>> I agree — my reasoning was that it’s more like the current iOS availability 
>> statement.
> 
> Is it? You can do `#available(iOS 9.2, *)` there.
> 
> — Radek
> 
>> On 18 Dec 2015, at 21:58, Harlan Haskins via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> I agree — my reasoning was that it’s more like the current iOS availability 
>> statement.
>> 
>> I wonder if the iOS availability statement could use some work too? It’s 
>> kinda weird and magical ("why do I have to type that *?")
>> 
>>> On Dec 18, 2015, at 3:56 PM, David Farler >> > wrote:
>>> 
>>> I had considered this format but I don't think it reads as well as you'd 
>>> expect for a version. It kind of makes it seem like each component is an 
>>> independent argument, each with possibly a different meaning. It makes 
>>> sense from a parsing point of view but I think we should allow folks to 
>>> write it the same way they'd write it in normal prose, since it's not much 
>>> more effort. 
>>> 
>>> David
>>> 
>>> On Dec 18, 2015, at 12:48, Harlan Haskins >> > wrote:
>>> 
 How about
 
 #if swift(2, 2, *)
 #endif
 
 ?
 
> On Dec 18, 2015, at 3:32 PM, David Farler via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> 
>> 
>> On Dec 18, 2015, at 12:29 PM, Chris Lattner > > wrote:
>> 
>> 
>>> On Dec 18, 2015, at 12:25 PM, Radosław Pietruszewski via 
>>> swift-evolution >> > wrote:
>>> 
>>> Sounds like it could be super useful for libraries!
>>> 
>>> How about we drop the quote marks, though? If we have `os(iOS)` and 
>>> `#available(iOS 9, *)` (in other context), why not `swift(2.2)`?
>> 
>> I agree with Radek.
>> 
>> The argument to use a string is if we wanted to support subversions, 
>> e.g. like “#if swift(2.2.1)”.  This requires the parameter to be a 
>> string, because 2.2.1 isn’t a valid floating point literal - the lexer 
>> will be displeased.
>> 
>> However, I don’t think we *want* the feature to be able to do that.  The 
>> most important use case for this feature is to handle syntactic 
>> differences across swift versions, and we don’t want those in 
>> sub-versions.  Given that, it seems better to keep the syntax clean and 
>> simple.
>> 
>> David know this already, but I’m a huge fan of this feature. :-)
>> 
>> -Chris
> 
> Yep, you took the words out of my mouth re: the version components. If 
> two components are enough though, then we should totally drop the quotes.
> 
> David
> 
>>> — Radek
>>> 
 On 18 Dec 2015, at 21:22, David Farler via swift-evolution 
 mailto:swift-evolution@swift.org>> wrote:
 
 Hello everyone,
 
 For Swift 2.2, I'd like to add the following build configuration to 
 check for the Swift language version. This is meant to be a short 
 proposal, so let's start with a simple example, compiling with the 2.2 
 compiler:
 
 #if swift("2.2")
 print("Hello")
 #else
 this code will not parse or emit diagnostics
 #endif
 
 The semantics of the build configuration is, "is the Swift language 
 version at least X?". If it is, the active block is parsed and 
 compiled into your program. Like the other build configuration blocks, 
 this isn't line-based, but break on whole statements and declarations. 
 Unlike the other build configurations, however, the inactive block 
 will not parse or emit syntax errors, so you can include syntax for 
 older Swift language revisions in the same file if you prefer.
 
 It sounds like a lot of folks have been wanting something like this, 
 which is why I'm suggesting it for the Swift 2.2 release. I'm curious 
 to hear your feedback!
 
 Best,
 David
 ___
 swift-evolution mailing list
 swift-evolution@swift.org 
 https://lists.swift.org/mailman/listinfo/swift-evolution 
 
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org 
>>> https://lists.swift.org/mailman/listinfo

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

[Radosław Pietruszewski via swift-evolution]

> I agree — my reasoning was that it’s more like the current iOS availability 
> statement.

Is it? You can do `#available(iOS 9.2, *)` there.

— Radek

> On 18 Dec 2015, at 21:58, Harlan Haskins via swift-evolution 
>  wrote:
> 
> I agree — my reasoning was that it’s more like the current iOS availability 
> statement.
> 
> I wonder if the iOS availability statement could use some work too? It’s 
> kinda weird and magical ("why do I have to type that *?")
> 
>> On Dec 18, 2015, at 3:56 PM, David Farler > > wrote:
>> 
>> I had considered this format but I don't think it reads as well as you'd 
>> expect for a version. It kind of makes it seem like each component is an 
>> independent argument, each with possibly a different meaning. It makes sense 
>> from a parsing point of view but I think we should allow folks to write it 
>> the same way they'd write it in normal prose, since it's not much more 
>> effort. 
>> 
>> David
>> 
>> On Dec 18, 2015, at 12:48, Harlan Haskins > > wrote:
>> 
>>> How about
>>> 
>>> #if swift(2, 2, *)
>>> #endif
>>> 
>>> ?
>>> 
 On Dec 18, 2015, at 3:32 PM, David Farler via swift-evolution 
 mailto:swift-evolution@swift.org>> wrote:
 
> 
> On Dec 18, 2015, at 12:29 PM, Chris Lattner  > wrote:
> 
> 
>> On Dec 18, 2015, at 12:25 PM, Radosław Pietruszewski via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> Sounds like it could be super useful for libraries!
>> 
>> How about we drop the quote marks, though? If we have `os(iOS)` and 
>> `#available(iOS 9, *)` (in other context), why not `swift(2.2)`?
> 
> I agree with Radek.
> 
> The argument to use a string is if we wanted to support subversions, e.g. 
> like “#if swift(2.2.1)”.  This requires the parameter to be a string, 
> because 2.2.1 isn’t a valid floating point literal - the lexer will be 
> displeased.
> 
> However, I don’t think we *want* the feature to be able to do that.  The 
> most important use case for this feature is to handle syntactic 
> differences across swift versions, and we don’t want those in 
> sub-versions.  Given that, it seems better to keep the syntax clean and 
> simple.
> 
> David know this already, but I’m a huge fan of this feature. :-)
> 
> -Chris
 
 Yep, you took the words out of my mouth re: the version components. If two 
 components are enough though, then we should totally drop the quotes.
 
 David
 
>> — Radek
>> 
>>> On 18 Dec 2015, at 21:22, David Farler via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> Hello everyone,
>>> 
>>> For Swift 2.2, I'd like to add the following build configuration to 
>>> check for the Swift language version. This is meant to be a short 
>>> proposal, so let's start with a simple example, compiling with the 2.2 
>>> compiler:
>>> 
>>> #if swift("2.2")
>>> print("Hello")
>>> #else
>>> this code will not parse or emit diagnostics
>>> #endif
>>> 
>>> The semantics of the build configuration is, "is the Swift language 
>>> version at least X?". If it is, the active block is parsed and compiled 
>>> into your program. Like the other build configuration blocks, this 
>>> isn't line-based, but break on whole statements and declarations. 
>>> Unlike the other build configurations, however, the inactive block will 
>>> not parse or emit syntax errors, so you can include syntax for older 
>>> Swift language revisions in the same file if you prefer.
>>> 
>>> It sounds like a lot of folks have been wanting something like this, 
>>> which is why I'm suggesting it for the Swift 2.2 release. I'm curious 
>>> to hear your feedback!
>>> 
>>> Best,
>>> David
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
> 
 
 ___
 swift-evolution mailing list
 swift-evolution@swift.org 
 https://lists.swift.org/mailman/listinfo/swift-evolution 
 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listin

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

[Harlan Haskins via swift-evolution]

I agree — my reasoning was that it’s more like the current iOS availability 
statement.

I wonder if the iOS availability statement could use some work too? It’s kinda 
weird and magical ("why do I have to type that *?")

> On Dec 18, 2015, at 3:56 PM, David Farler  wrote:
> 
> I had considered this format but I don't think it reads as well as you'd 
> expect for a version. It kind of makes it seem like each component is an 
> independent argument, each with possibly a different meaning. It makes sense 
> from a parsing point of view but I think we should allow folks to write it 
> the same way they'd write it in normal prose, since it's not much more 
> effort. 
> 
> David
> 
> On Dec 18, 2015, at 12:48, Harlan Haskins  > wrote:
> 
>> How about
>> 
>> #if swift(2, 2, *)
>> #endif
>> 
>> ?
>> 
>>> On Dec 18, 2015, at 3:32 PM, David Farler via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
 
 On Dec 18, 2015, at 12:29 PM, Chris Lattner >>> > wrote:
 
 
> On Dec 18, 2015, at 12:25 PM, Radosław Pietruszewski via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> 
> Sounds like it could be super useful for libraries!
> 
> How about we drop the quote marks, though? If we have `os(iOS)` and 
> `#available(iOS 9, *)` (in other context), why not `swift(2.2)`?
 
 I agree with Radek.
 
 The argument to use a string is if we wanted to support subversions, e.g. 
 like “#if swift(2.2.1)”.  This requires the parameter to be a string, 
 because 2.2.1 isn’t a valid floating point literal - the lexer will be 
 displeased.
 
 However, I don’t think we *want* the feature to be able to do that.  The 
 most important use case for this feature is to handle syntactic 
 differences across swift versions, and we don’t want those in 
 sub-versions.  Given that, it seems better to keep the syntax clean and 
 simple.
 
 David know this already, but I’m a huge fan of this feature. :-)
 
 -Chris
>>> 
>>> Yep, you took the words out of my mouth re: the version components. If two 
>>> components are enough though, then we should totally drop the quotes.
>>> 
>>> David
>>> 
> — Radek
> 
>> On 18 Dec 2015, at 21:22, David Farler via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> Hello everyone,
>> 
>> For Swift 2.2, I'd like to add the following build configuration to 
>> check for the Swift language version. This is meant to be a short 
>> proposal, so let's start with a simple example, compiling with the 2.2 
>> compiler:
>> 
>> #if swift("2.2")
>> print("Hello")
>> #else
>> this code will not parse or emit diagnostics
>> #endif
>> 
>> The semantics of the build configuration is, "is the Swift language 
>> version at least X?". If it is, the active block is parsed and compiled 
>> into your program. Like the other build configuration blocks, this isn't 
>> line-based, but break on whole statements and declarations. Unlike the 
>> other build configurations, however, the inactive block will not parse 
>> or emit syntax errors, so you can include syntax for older Swift 
>> language revisions in the same file if you prefer.
>> 
>> It sounds like a lot of folks have been wanting something like this, 
>> which is why I'm suggesting it for the Swift 2.2 release. I'm curious to 
>> hear your feedback!
>> 
>> Best,
>> David
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
 
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> 



smime.p7s
Description: S/MIME cryptographic signature
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[David Farler via swift-evolution]

I had considered this format but I don't think it reads as well as you'd expect 
for a version. It kind of makes it seem like each component is an independent 
argument, each with possibly a different meaning. It makes sense from a parsing 
point of view but I think we should allow folks to write it the same way they'd 
write it in normal prose, since it's not much more effort. 

David

> On Dec 18, 2015, at 12:48, Harlan Haskins  wrote:
> 
> How about
> 
> #if swift(2, 2, *)
> #endif
> 
> ?
> 
>>> On Dec 18, 2015, at 3:32 PM, David Farler via swift-evolution 
>>>  wrote:
>>> 
>>> 
 On Dec 18, 2015, at 12:29 PM, Chris Lattner  wrote:
 
 
 On Dec 18, 2015, at 12:25 PM, Radosław Pietruszewski via swift-evolution 
  wrote:
 
 Sounds like it could be super useful for libraries!
 
 How about we drop the quote marks, though? If we have `os(iOS)` and 
 `#available(iOS 9, *)` (in other context), why not `swift(2.2)`?
>>> 
>>> I agree with Radek.
>>> 
>>> The argument to use a string is if we wanted to support subversions, e.g. 
>>> like “#if swift(2.2.1)”.  This requires the parameter to be a string, 
>>> because 2.2.1 isn’t a valid floating point literal - the lexer will be 
>>> displeased.
>>> 
>>> However, I don’t think we *want* the feature to be able to do that.  The 
>>> most important use case for this feature is to handle syntactic differences 
>>> across swift versions, and we don’t want those in sub-versions.  Given 
>>> that, it seems better to keep the syntax clean and simple.
>>> 
>>> David know this already, but I’m a huge fan of this feature. :-)
>>> 
>>> -Chris
>> 
>> Yep, you took the words out of my mouth re: the version components. If two 
>> components are enough though, then we should totally drop the quotes.
>> 
>> David
>> 
 — Radek
 
> On 18 Dec 2015, at 21:22, David Farler via swift-evolution 
>  wrote:
> 
> Hello everyone,
> 
> For Swift 2.2, I'd like to add the following build configuration to check 
> for the Swift language version. This is meant to be a short proposal, so 
> let's start with a simple example, compiling with the 2.2 compiler:
> 
> #if swift("2.2")
> print("Hello")
> #else
> this code will not parse or emit diagnostics
> #endif
> 
> The semantics of the build configuration is, "is the Swift language 
> version at least X?". If it is, the active block is parsed and compiled 
> into your program. Like the other build configuration blocks, this isn't 
> line-based, but break on whole statements and declarations. Unlike the 
> other build configurations, however, the inactive block will not parse or 
> emit syntax errors, so you can include syntax for older Swift language 
> revisions in the same file if you prefer.
> 
> It sounds like a lot of folks have been wanting something like this, 
> which is why I'm suggesting it for the Swift 2.2 release. I'm curious to 
> hear your feedback!
> 
> Best,
> David
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
 
 ___
 swift-evolution mailing list
 swift-evolution@swift.org
 https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Harlan Haskins via swift-evolution]

How about

#if swift(2, 2, *)
#endif

?

> On Dec 18, 2015, at 3:32 PM, David Farler via swift-evolution 
>  wrote:
> 
>> 
>> On Dec 18, 2015, at 12:29 PM, Chris Lattner  wrote:
>> 
>> 
>>> On Dec 18, 2015, at 12:25 PM, Radosław Pietruszewski via swift-evolution 
>>>  wrote:
>>> 
>>> Sounds like it could be super useful for libraries!
>>> 
>>> How about we drop the quote marks, though? If we have `os(iOS)` and 
>>> `#available(iOS 9, *)` (in other context), why not `swift(2.2)`?
>> 
>> I agree with Radek.
>> 
>> The argument to use a string is if we wanted to support subversions, e.g. 
>> like “#if swift(2.2.1)”.  This requires the parameter to be a string, 
>> because 2.2.1 isn’t a valid floating point literal - the lexer will be 
>> displeased.
>> 
>> However, I don’t think we *want* the feature to be able to do that.  The 
>> most important use case for this feature is to handle syntactic differences 
>> across swift versions, and we don’t want those in sub-versions.  Given that, 
>> it seems better to keep the syntax clean and simple.
>> 
>> David know this already, but I’m a huge fan of this feature. :-)
>> 
>> -Chris
> 
> Yep, you took the words out of my mouth re: the version components. If two 
> components are enough though, then we should totally drop the quotes.
> 
> David
> 
>>> — Radek
>>> 
 On 18 Dec 2015, at 21:22, David Farler via swift-evolution 
  wrote:
 
 Hello everyone,
 
 For Swift 2.2, I'd like to add the following build configuration to check 
 for the Swift language version. This is meant to be a short proposal, so 
 let's start with a simple example, compiling with the 2.2 compiler:
 
 #if swift("2.2")
 print("Hello")
 #else
 this code will not parse or emit diagnostics
 #endif
 
 The semantics of the build configuration is, "is the Swift language 
 version at least X?". If it is, the active block is parsed and compiled 
 into your program. Like the other build configuration blocks, this isn't 
 line-based, but break on whole statements and declarations. Unlike the 
 other build configurations, however, the inactive block will not parse or 
 emit syntax errors, so you can include syntax for older Swift language 
 revisions in the same file if you prefer.
 
 It sounds like a lot of folks have been wanting something like this, which 
 is why I'm suggesting it for the Swift 2.2 release. I'm curious to hear 
 your feedback!
 
 Best,
 David
 ___
 swift-evolution mailing list
 swift-evolution@swift.org
 https://lists.swift.org/mailman/listinfo/swift-evolution
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution



smime.p7s
Description: S/MIME cryptographic signature
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[David Farler via swift-evolution]

> On Dec 18, 2015, at 12:29 PM, Chris Lattner  wrote:
> 
> 
>> On Dec 18, 2015, at 12:25 PM, Radosław Pietruszewski via swift-evolution 
>>  wrote:
>> 
>> Sounds like it could be super useful for libraries!
>> 
>> How about we drop the quote marks, though? If we have `os(iOS)` and 
>> `#available(iOS 9, *)` (in other context), why not `swift(2.2)`?
> 
> I agree with Radek.
> 
> The argument to use a string is if we wanted to support subversions, e.g. 
> like “#if swift(2.2.1)”.  This requires the parameter to be a string, because 
> 2.2.1 isn’t a valid floating point literal - the lexer will be displeased.
> 
> However, I don’t think we *want* the feature to be able to do that.  The most 
> important use case for this feature is to handle syntactic differences across 
> swift versions, and we don’t want those in sub-versions.  Given that, it 
> seems better to keep the syntax clean and simple.
> 
> David know this already, but I’m a huge fan of this feature. :-)
> 
> -Chris

Yep, you took the words out of my mouth re: the version components. If two 
components are enough though, then we should totally drop the quotes.

David

>> — Radek
>> 
>>> On 18 Dec 2015, at 21:22, David Farler via swift-evolution 
>>>  wrote:
>>> 
>>> Hello everyone,
>>> 
>>> For Swift 2.2, I'd like to add the following build configuration to check 
>>> for the Swift language version. This is meant to be a short proposal, so 
>>> let's start with a simple example, compiling with the 2.2 compiler:
>>> 
>>> #if swift("2.2")
>>> print("Hello")
>>> #else
>>> this code will not parse or emit diagnostics
>>> #endif
>>> 
>>> The semantics of the build configuration is, "is the Swift language version 
>>> at least X?". If it is, the active block is parsed and compiled into your 
>>> program. Like the other build configuration blocks, this isn't line-based, 
>>> but break on whole statements and declarations. Unlike the other build 
>>> configurations, however, the inactive block will not parse or emit syntax 
>>> errors, so you can include syntax for older Swift language revisions in the 
>>> same file if you prefer.
>>> 
>>> It sounds like a lot of folks have been wanting something like this, which 
>>> is why I'm suggesting it for the Swift 2.2 release. I'm curious to hear 
>>> your feedback!
>>> 
>>> Best,
>>> David
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Chris Lattner via swift-evolution]

> On Dec 18, 2015, at 12:25 PM, Radosław Pietruszewski via swift-evolution 
>  wrote:
> 
> Sounds like it could be super useful for libraries!
> 
> How about we drop the quote marks, though? If we have `os(iOS)` and 
> `#available(iOS 9, *)` (in other context), why not `swift(2.2)`?

I agree with Radek.

The argument to use a string is if we wanted to support subversions, e.g. like 
“#if swift(2.2.1)”.  This requires the parameter to be a string, because 2.2.1 
isn’t a valid floating point literal - the lexer will be displeased.

However, I don’t think we *want* the feature to be able to do that.  The most 
important use case for this feature is to handle syntactic differences across 
swift versions, and we don’t want those in sub-versions.  Given that, it seems 
better to keep the syntax clean and simple.

David know this already, but I’m a huge fan of this feature. :-)

-Chris

> 
> — Radek
> 
>> On 18 Dec 2015, at 21:22, David Farler via swift-evolution 
>>  wrote:
>> 
>> Hello everyone,
>> 
>> For Swift 2.2, I'd like to add the following build configuration to check 
>> for the Swift language version. This is meant to be a short proposal, so 
>> let's start with a simple example, compiling with the 2.2 compiler:
>> 
>> #if swift("2.2")
>> print("Hello")
>> #else
>> this code will not parse or emit diagnostics
>> #endif
>> 
>> The semantics of the build configuration is, "is the Swift language version 
>> at least X?". If it is, the active block is parsed and compiled into your 
>> program. Like the other build configuration blocks, this isn't line-based, 
>> but break on whole statements and declarations. Unlike the other build 
>> configurations, however, the inactive block will not parse or emit syntax 
>> errors, so you can include syntax for older Swift language revisions in the 
>> same file if you prefer.
>> 
>> It sounds like a lot of folks have been wanting something like this, which 
>> is why I'm suggesting it for the Swift 2.2 release. I'm curious to hear your 
>> feedback!
>> 
>> Best,
>> David
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Radosław Pietruszewski via swift-evolution]

Sounds like it could be super useful for libraries!

How about we drop the quote marks, though? If we have `os(iOS)` and 
`#available(iOS 9, *)` (in other context), why not `swift(2.2)`?

— Radek

> On 18 Dec 2015, at 21:22, David Farler via swift-evolution 
>  wrote:
> 
> Hello everyone,
> 
> For Swift 2.2, I'd like to add the following build configuration to check for 
> the Swift language version. This is meant to be a short proposal, so let's 
> start with a simple example, compiling with the 2.2 compiler:
> 
> #if swift("2.2")
>  print("Hello")
> #else
>  this code will not parse or emit diagnostics
> #endif
> 
> The semantics of the build configuration is, "is the Swift language version 
> at least X?". If it is, the active block is parsed and compiled into your 
> program. Like the other build configuration blocks, this isn't line-based, 
> but break on whole statements and declarations. Unlike the other build 
> configurations, however, the inactive block will not parse or emit syntax 
> errors, so you can include syntax for older Swift language revisions in the 
> same file if you prefer.
> 
> It sounds like a lot of folks have been wanting something like this, which is 
> why I'm suggesting it for the Swift 2.2 release. I'm curious to hear your 
> feedback!
> 
> Best,
> David
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[David Farler via swift-evolution]

Hello everyone,

For Swift 2.2, I'd like to add the following build configuration to check for 
the Swift language version. This is meant to be a short proposal, so let's 
start with a simple example, compiling with the 2.2 compiler:

#if swift("2.2")
  print("Hello")
#else
  this code will not parse or emit diagnostics
#endif

The semantics of the build configuration is, "is the Swift language version at 
least X?". If it is, the active block is parsed and compiled into your program. 
Like the other build configuration blocks, this isn't line-based, but break on 
whole statements and declarations. Unlike the other build configurations, 
however, the inactive block will not parse or emit syntax errors, so you can 
include syntax for older Swift language revisions in the same file if you 
prefer.

It sounds like a lot of folks have been wanting something like this, which is 
why I'm suggesting it for the Swift 2.2 release. I'm curious to hear your 
feedback!

Best,
David
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution