[swift-evolution] [Review] SE-0056: Allow trailing closures in `guard` conditions

[Dany St-Amant]

> Le 4 avr. 2016 à 10:19, Patrick Gili <gili.patrick.r at gili-labs.com> a écrit :
> 
> If I understand you correctly, you think adding keywords represents an inconsistency.

I didn't write that, maybe I should have put my reply between your two paragraphs. Adding keywords such as 'then' and 'do' could add some consistency, but another word than 'do' will likely have to be found as 'do' could break code as highlighted by Xiaodi, as well as cause by the 'catch' case caught by Jeremy.

I was merely highlighting the current inconsistency of the variable scope of 'guard let' versus 'if let' which no one had mentioned so far... An inconsistency which is (logically) fully design intent and will remain forever. So some inconsistencies are acceptable, 

Is accepting trailing closure in 'guard' really a new inconsistency?
Being unable to use them with 'guard', 'if', 'switch' is the original inconsistency as the trailing closure seemed to be use in many places (including argument list of another function). Adding 'guard' as a location where trailing closure are allowed doesn't really introduce a new inconsistency, it just incompletely reduce an existing inconsistency.

> However, I think it would add considerable consistency and utility to the Swift language. Yes, it would make it inconsistent with the generations of C-like languages that have come before it. However, I think we've already taken considerable steps from away from C-like languages; for example, removing C-like for-loop syntax and unary increment/decrement operators.

I am with you here, Swift is Swift, C is C, Swift should not be hampered by keeping the syntax identical to C. But, it seems that most prefer to type less, so we should be really careful with proposing new keywords like this 'then' and 'do' as they carry little meaning,  have to be mandatory (as per Chris), and are really needed only for trailing closure which will not be used by everyone.

So, I'm against adding these 'then' and 'do' keywords for the sake of providing the trailing support to 'if' and 'for'. And I do not see why we should prevent 'guard' from gaining this support just because the 'if' and 'for' doesn't also have it.

Dany
 
> 
>> On Apr 3, 2016, at 11:44 AM, Dany St-Amant via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> 
>> Le 2 avr. 2016 à 15:39, Patrick Gili via swift-evolution <swift-evolution at swift.org> a écrit :
>> 
>>>> What is your evaluation of the proposal?
>>> I think there is a lot of value to allowing trailing closures in the guard condition clause. However, not at the cost of inconsistency. We have reviewed many proposals over the last month that addressed consistency issues in the Swift language, and if I'm not mistaken, all of them have been accepted by the community, larger to eliminate the inconsistency.
>>> 
>>> Because of this, I think two of the alternatives stated by the proposal have credibility:
>>> 1) Eliminate the "else" keyword from the guard syntax.
>>> 2) Add keywords to "if", "while", "for", and "switch" to delineate the condition clause from the body of the statement.
>>> 
>>> The second alternative has more appeal, because it supports trailing closures without "heroics".
>> 
>> It have been mentioned multiple times that allowing trailing closure only for guard is creating an inconsistency, but these keywords already are inconsistent with the each other (beside the presence of the 'trailing' else keyword) on the variable scoping:
>> 
>> - guard let: outer scope immutable variable
>> - if let: inner scope immutable variable
>> - for: inner scope immutable variable without let keyword
>> 
>> Consistency is good, but since each keywords are not for the exact same thing, it is normal to see some variances.  Like the global scope of the immutable variable created by guard; as per the intent of the keyword, or its trailing else keyword; needed to clarify that what follow is for, for lack of better word, the 'else' case.
>> 
>> So as long as such inconsistency have a "raison d'être", that they have been designed and are not an oversight; there should be no reason to not allow them.
>> 
>> Dany
>> 
>>> 
>>>> Is the problem being addressed significant enough to warrant a change to Swift?
>>> No.
>>> 
>>>> Does this proposal fit well with the feel and direction of Swift?
>>> No. Please don't add inconsistencies to the language, as we're just going to have to deal with it down the road.
>>> 
>>>> If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
>>> Not in my experience.
>>> 
>>>> How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
>>> 
>>> In-depth study.
>>> 
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160404/fee6685a/attachment.html>