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

[Patrick Gili]

If I understand you correctly, you think adding keywords represents an 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.

-Patrick

> 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 <mailto: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 <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160404/fad55a11/attachment.html>