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

[David Farler]

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 <felixcca at yahoo.ca> 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 <dfarler at apple.com> 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)
>> 2    print("Hello")
>> 3  #else
>> 4    print("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='<null>'
>> 
>> ...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 <felixcca at yahoo.ca> wrote:
>>> 
>>> I don't really like how different this makes "#if swift" from "#if <anything 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 <swift-evolution at swift.org> a écrit :
>>>> 
>>>> 
>>>> 
>>>>>> On Dec 19, 2015, at 13:48, Michel Fortin <michel.fortin at michelf.ca> wrote:
>>>>>> 
>>>>>> Le 18 déc. 2015 à 15:22, David Farler via swift-evolution <swift-evolution at swift.org> 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 at 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 at swift.org
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>