<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Jun 8, 2016 at 11:17 PM, Sean Heber via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></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 class=""><div><br></div><div>On Jun 8, 2016, at 10:51 PM, Erica Sadun via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> 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 <<a href="mailto:brent@architechies.com" target="_blank">brent@architechies.com</a>> wrote:</div><br><div><div><blockquote type="cite">Upon accepting SE-0099, the core team is removing `where` clauses from condition clauses, writing "the 'where' keyword can be retired from its purpose as a boolean condition introducer." <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'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 'where' makes total sense and I really like it there.<span class=""><div><br></div><br><blockquote type="cite"><div><div>I agree that'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'm going to stick to my guns on this one - and for `for case` too. I've been wuxxed.</div></div></blockquote></span></div></blockquote><div><br></div><div>Maybe it'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'll form a considered preference.</div><div><br></div><div>Brent'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's if we'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's a win.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><span class=""><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 "this is a filtering operation"</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 'where' 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've found *significant* speed ups switching .forEach() with for loops in debug builds, for example.)</div><span class=""><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'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 "prefix" means here (normally I only think of prefix in the context of strings) and if there's a special variation of it using the "while" argument that I need to also be aware of...</div><div><br></div><div>Maybe it's just me, but.. I don't get it. I want to be able to quickly understand a piece of code'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>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">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>