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 > <[email protected]> wrote: > > > Le 2 avr. 2016 à 15:39, Patrick Gili via swift-evolution > <[email protected] <mailto:[email protected]>> 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 >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> > _______________________________________________ > swift-evolution mailing list > [email protected] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
