<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jun 23, 2016, at 7:42 AM, Ryan Lovelett via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><div class=""><div class=""><blockquote type="cite" class="">Is the problem being addressed significant enough to warrant a change to Swift?<br class=""></blockquote><br class="">No. In fact, I think that even the proposal itself says as much. The<br class="">proposal indicates it means to deprecate an available coding style. It<br class="">seems to me, as much as is practicable, style changes should be enforced<br class="">by something other than the Swift compiler.<br class=""><br class=""></div></div></blockquote></div><br class=""><div class="">I in no way intended the proposal to "say as much".</div><div class=""><br class=""></div><div class=""><span style="font-family: Palatino-Roman;" class="">As syntactic sugar, the filtering syntax is </span></div><div class=""><ul class="MailOutline"><li class=""><span style="font-family: Palatino-Roman;" class="">rarely used in published deployed code, </span></li><li class=""><span style="font-family: Palatino-Roman;" class="">hard to discover (although I like others have taught it to promote its visibility),</span></li><li class=""><span style="font-family: Palatino-Roman;" class="">elevates one style (continue if false) above others (continue if false, break if true, break if false), which are not expressible using similar shorthand,</span></li><li class=""><span style="font-family: Palatino-Roman;" class="">introduces a fluent style that discourages design comments at the point of use,</span></li><li class=""><span style="font-family: Palatino-Roman;" class="">can be difficult to breakpoint during debugging. </span></li></ul></div><div class=""><span style="font-family: Palatino-Roman;" class=""><br class=""></span></div><div class=""><span style="font-family: Palatino-Roman;" class="">I think these are significant issues.</span></div><div class=""><span style="font-family: Palatino-Roman;" class=""><br class=""></span></div><div class=""><span style="font-family: Palatino-Roman;" class="">The recommended alternative (using a separate guard) addresses all these points: better commenting, better breakpointing and debugging, and fully covers the domain of filtering and early exiting. </span><span style="font-family: Palatino-Roman;" class="">If chaining is desired, using filter and prefix(while:) address all conditions, allow better commenting, etc, and are more self-documenting.</span></div><div class=""><font face="Palatino-Roman" class=""><br class=""></font></div><div class=""><blockquote type="cite" class=""><div class="">On Jun 23, 2016, at 9:07 AM, Tony Allevato via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><div class=""><div dir="ltr" class="" style="font-family: Palatino-Roman;"><div class="gmail_quote"><div class="">The fact that some users may be confused by this terminology is not a reason to remove it from the language. Some users will be confused by many concepts in programming languages. If that means this is considered an "advanced" feature, so be it. We should be able to have a language that has both basic features and advanced features, and when a new developer comes across a feature they don't understand, they learn it, and then they know it. This is not an insurmountable problem.</div></div></div></div></blockquote><br class=""></div><div class="">For the advanced user, filter and prefix are more customizable and provide greater coverage of cases involving fine control over sequences.</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div class="">On Jun 23, 2016, at 3:02 AM, Jonathan Hull via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class="">I just taught this to a class of newbies last week and exactly zero of them had trouble with it. I told my TA that we were debating removing it, and he was horrified. “It is one of the best features of Swift!” he said. I agree. It is one of the things which gives Swift character and makes it fun.</div></div></div></blockquote><br class=""></div><div class="">I have also taught this construct, which is always a counterpoint to discoverability issues.</div><div class=""><br class=""></div><div class="">If you step back and ask: "If this feature were not in the language already, would it be added?", we would have to discuss why "positive filtering" should be prioritized as it is and if we include it, what syntax would least confuse users encountering it for the first time. Surrounded as I am by learner-developers, I recognize that this is a real stumbling block -- no matter how ubiquitous it is in SQL, for example -- and have provided examples of both new and experienced developers being confused. </div><div class=""><br class=""></div><div class="">For any feature to be included, it should provide measurable benefits, fix a real problem, be named well, be discoverable, and provide non-trivial utility. I think "where", while convenient for a very narrow case of use, fails these tests.</div><div class=""><br class=""></div><div class=""><span style="font-family: Palatino-Roman;" class="">-- Erica</span></div><div class=""><span style="font-family: Palatino-Roman;" class=""><br class=""></span></div></body></html>