<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Jun 8, 2016 at 11:34 PM, Xiaodi Wu <span dir="ltr">&lt;<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.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 dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="">On Wed, Jun 8, 2016 at 11:17 PM, Sean Heber via swift-evolution <span dir="ltr">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><span><div><br></div><div>On Jun 8, 2016, at 10:51 PM, Erica Sadun via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:<br><br></div><blockquote type="cite"><div><br><div><blockquote type="cite"><div>On Jun 8, 2016, at 9:36 PM, Brent Royal-Gordon &lt;<a href="mailto:brent@architechies.com" target="_blank">brent@architechies.com</a>&gt; wrote:</div><br><div><div><blockquote type="cite">Upon accepting SE-0099, the core team is removing `where` clauses from condition clauses, writing &quot;the &#39;where&#39; keyword can be retired from its purpose as a boolean condition introducer.&quot; <br><br>Inspiried by Xiaodi Wu, I now propose removing `where` clauses from `for in` loops, where they are better expressed (and read) as guard conditions. <br></blockquote><br>Do you propose to remove `for case` as well? That can equally be handled by a `guard case` in the loop body.<br><br>Alternate proposal: Move `where` clauses to be adjacent to the pattern—rather than the sequence expression—in a `for` loop, just as they are in these other syntaxes.<br><br><span style="white-space:pre-wrap">        </span>for n where n.isOdd in 1...1_000 { … }<br><br>This makes them more consistent with the syntax in `switch` cases and `catch` statements, while also IMHO clarifying the role of the `where` clause as a filter on the elements seen by the loop.<br></div></div></blockquote></div><br><div>I saw your post on that *after* I finished sending this. Moving `where` next to the pattern, like you&#39;d find in `catch` and switch `case`, the code would look like this:</div><div><br></div><div><font face="Menlo">for i where i % 2 == 0 in sequence {</font></div><div><font face="Menlo">    // do stuff</font></div><div><font face="Menlo">}</font></div></div></blockquote><div><br></div></span>This is the best version yet - the placement of &#39;where&#39; makes total sense and I really like it there.<span><div><br></div><br><blockquote type="cite"><div><div>I agree that&#39;s really clever and an improvement but after coming up with all the points about wrong expectations about termination vs filtering, the better use of guard, and fetishes about vertical compactness, I think (call it +0.6) I&#39;m going to stick to my guns on this one - and for `for case` too. I&#39;ve been wuxxed.</div></div></blockquote></span></div></blockquote><div><br></div></span><div>Maybe it&#39;s the late hour and staring at this too much. For the moment I think I could live with either not having `where` like Erica proposes or having it moved like Brent proposes. Perhaps later I&#39;ll form a considered preference.</div><div><br></div><div>Brent&#39;s idea is so new, yet I have to admit it does feel somehow--this is a squishy evaluation--satisfying? One thing about it that I like over previous proposals--that&#39;s if we&#39;re going to go down this route rather than taking out `while` altogether--is that the word `in` seems to instinctively encourage concision. It just feels weird to stuff too much between `for i` and `in`, so I think people will tend to use it in a more reasonable way (with nothing to prove this intuition at all, of course).</div><div><br></div><div>Then again, it should come as no surprise that I agree with Erica that removing `while` altogether has the benefit of definitively eliminating any kind of misinterpretation as to termination vs. filtering. That&#39;s a win.</div></div></div></div></blockquote><div><br></div><div>Yikes: s/while/where. That&#39;s my queue to quit for the day.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><div dir="auto"><span><blockquote type="cite"><div><div>* New users might expect the sequence to terminate as soon as i % 2 is 1, rather than the correct interpretation which is &quot;this is a filtering operation&quot;</div><div>* The code can be expressed less ambiguously as </div><div><br></div><div><font face="Menlo">for i in sequence.filter({ return i % 2 == 0 }) {</font></div><div><font face="Menlo">    // do stuff</font></div><div><font face="Menlo">}</font></div></div></blockquote><div><br></div></span><div>This seems to trade what was a very declarative syntax about the intent of some code (especially with &#39;where&#39; in the middle of the statement) for one that injects its own specialized vocabulary into the context (knowing what filter does, a function call, a closure with a return keyword and a pair of extra braces and parenthesis!) which means, to me anyway, significant cognitive overhead. It will also be a lot slower without optimization enabled due to the intermediate array. (I&#39;ve found *significant* speed ups switching .forEach() with for loops in debug builds, for example.)</div><span><div><br></div><br><blockquote type="cite"><div><div>* The while version can be expressed as</div><div><br></div><div><font face="Menlo">for i in sequence.prefix(while: { return $0 % 2 == 0 } ) {</font></div><div><font face="Menlo">    // do stuff</font></div><div><font face="Menlo">}</font></div></div></blockquote><div><br></div></span><div>And now we&#39;ve gone from, again, what is likely a very simple and declarative style using a for/while kind of statement and turned it in to something that has *even more* cognitive overhead to figure out what it does because now I have to reason about what &quot;prefix&quot; means here (normally I only think of prefix in the context of strings) and if there&#39;s a special variation of it using the &quot;while&quot; argument that I need to also be aware of...</div><div><br></div><div>Maybe it&#39;s just me, but.. I don&#39;t get it. I want to be able to quickly understand a piece of code&#39;s intent, not wade through fancy constructions for their own sake.</div><div><br></div><div>l8r</div><div>Sean - who might be too tired to be emailing responsibly </div><div><br></div></div><br></span>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br></blockquote></div><br></div></div>
</blockquote></div><br></div></div>