<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Jun 13, 2016 at 10:54 AM, Erica Sadun <span dir="ltr">&lt;<a href="mailto:erica@ericasadun.com" target="_blank">erica@ericasadun.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><span class=""><br><div><blockquote type="cite"><div>On Jun 13, 2016, at 9:44 AM, let var go via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:</div><br><div><div dir="ltr">I think we must be reading different discussions.<div><br></div><div>What I have seen in this discussion is the following:</div><div><br></div><div>a) The need to filter a for-in loop doesn&#39;t arise that often; but,</div><div>b) When it does arise, everyone who has chimed in on this thread (except the two people who are proposing the change) thinks that the &quot;where&quot; clause is the clearest, most expressive way to do it.</div></div></div></blockquote></div><br></span><div>As a point of order, may I request you stop singling out &quot;the two people who are proposing the change&quot; and discuss the merits of the pitch rather than the people involved in the discussion. Details of the Swift community code of conduct can be found here: <a href="https://swift.org/community/#code-of-conduct" target="_blank">https://swift.org/community/#code-of-conduct</a></div><div><br></div><div>As syntactic sugar, the filtering syntax is rarely used, hard to discover, and elevates one style (continue if false) above others (continue if false, break if true, break if false</div></div></blockquote><div><br></div><div>...and, a surprising number I noted from doing a rough GitHub search (many more than I thought I would see): return if true, return if false, fatalError if true, fatalError if false.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>), which are not expressible using similar shorthand. It introduces a fluent style that discourages design comments at the point of use and can be difficult to breakpoint during debugging. 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.</div><div><br></div><div>In response, I&#39;d like to hear why &quot;continue if false&quot; should be prioritized above the other options and should be retained, or alternatively why the suite should be completed (as in the original discussion with &quot;while&quot;) in preference to the advantages accrued by guard.</div><div><br></div><div>Thank you,</div><div><br></div><div>-- Erica</div></div></blockquote></div><br></div></div>