<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Mon, Jun 13, 2016 at 8:54 AM Erica Sadun &lt;<a href="mailto:erica@ericasadun.com">erica@ericasadun.com</a>&gt; wrote:<br></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"><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></div><div style="word-wrap:break-word"><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), 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></blockquote><div><span style="line-height:1.5"><br></span></div><div>The way you broke it down into the four different categories was helpful to me - I hadn&#39;t thought of it that way before. Here&#39;s may take on it:</div><div><br></div><div><ul><li><span style="line-height:1.5">&quot;continue if false&quot;</span><br></li><ul><li><span style="line-height:1.5">This is the current &#39;where` keyword. </span></li></ul><li>&quot;continue if true&quot;</li><ul><li>This is the inverse of the current &#39;where&#39; option. Because it is the inverse, it doesn&#39;t need a separate keyword. You just add the logical not &#39;!&#39; to the predicate, or just reverse the test, to obtain the inverse filtering operation. </li><li>So, for example, `for string in strings where string.hasPrefix(&quot;somePrefix&quot;)` becomes `for string in strings where !string.hasPrefix(&quot;somePrefix&quot;)`; or `for x in xs where x &lt; 5`, becomes `for x in xs where x &gt;= 5`</li><li>Using a single keyword but reversing the predicate isn&#39;t the only approach but it has the advantage of not polluting the language with unnecessary keywords where a single keyword can do the job.</li></ul><li>&quot;break if false&quot;</li><ul><li>In this scenario, you start looping through a collection, but exit early when some condition is no longer true. It combines a for...in loop with a &#39;while&#39; loop.</li><li>This construct would allow you to set a condition for early exit from the loop. The problem I see with this is that when I need to exit a loop early, I usually need to do something else first, like assign a value to a variable, or take some other action. So for example, I might do something like this:</li></ul></ul><div>var nextEvent: Event?</div>for event in events {</div><div>    if event.time &gt;= now  {</div><div>        nextEvent = event</div><div>        break</div><div>    }</div><div>}</div><div><ul><ul><li>The point is that before I could use &#39;break&#39;, I had to take some action (assign a value to nextEvent). So just defining an early exit condition wouldn&#39;t really work. I&#39;m trying to think of a use-case where I would want to exit early without doing anything first, and I can&#39;t. Given the appropriate use case, however, I could see a place for a keyword that did this like &#39;until&#39;, or &#39;while&#39;. Until then, though, I wouldn&#39;t create a keyword for something that doesn&#39;t have a common use. Filtering with &#39;where&#39; is at least used sometimes, even if it isn&#39;t the most common pattern on the planet.</li></ul><li>&quot;break if true&quot;</li><ul><li>I would apply the same arguments in &quot;break if false&quot;</li></ul></ul>So I would say that &quot;continue if false&quot; and &quot;continue if true&quot; are accomplished using the same keyword, and &quot;break if false&quot; and &quot;break if true&quot; don&#39;t have demonstrated use cases that can be solved with a keyword/predicate combination - early exit usually requires some additional action other than just exiting which couldn&#39;t be easily baked into the keyword.</div><div><span style="line-height:1.5"> </span><br></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><br></div><div>Thank you,</div><div><br></div><div>-- Erica</div></div></blockquote></div></div>