<div dir="ltr">On Fri, Jun 24, 2016 at 1:38 PM, Tony Allevato <span dir="ltr"><<a href="mailto:allevato@google.com" target="_blank">allevato@google.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><div class="h5"><div dir="ltr">On Fri, Jun 24, 2016 at 11:30 AM Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">On Fri, Jun 24, 2016 at 6:37 AM, William Shipley <span dir="ltr"><<a href="mailto:wjs@mac.com" target="_blank">wjs@mac.com</a>></span> wrote:<br></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><span>On Jun 23, 2016, at 11:04 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>> wrote:<br></span><span><div><blockquote type="cite"><br><div><div style="font-family:HelveticaNeue;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">Not a practitioner of 80-character line limits, I take it?</div></div></blockquote><br></div></span><div>I don’t understand why anyone wouldn’t just let Xcode do the wrapping for most cases. I’ll add newlines if I think it adds to clarity, but in general I don’t want to code like i’m still on a Wyse WY-50.</div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Of course, to each their own style--I certainly wouldn't want Swift to force everyone to write lines of certain lengths. But 80-character lines is a common style, and I would say that a corollary of "to each their own" is that Swift's grammar should be usable and useful whether or not you adhere to such style choices.</div><div><br></div><div>If the chief advantage of `where` is that it (quoting someone above) allows one to "<span style="font-size:13px">understand as much as possible about the control flow of the loop from a single line of code," then we ought perhaps to question its appropriateness when the majority of its benefits [by which I mean, based on your examples and Sean's, more than half of the instances in which it is used] cannot be realized in a very common coding style.</span></div></div></div></div></blockquote><div><br></div></div></div><div>IMO, we shouldn't be talking about "a single line of code" so much as "a single cohesive construct". What's important to me isn't the line length or whether the "where" part has to wrap onto another line, it's the number of potentially divergent constructs I have to parse mentally in order to determine the meaning of the loop.</div><div><br></div><div>With "for-in-where", it's three:</div><div><br></div><div> for item(1) in someCollection(2) where someCondition(3)</div><div><br></div><div>With the alternatives suggested using if/guard/continue/break, it's more than that:</div><div><br></div><div> for item(1) in someCollection(2) {</div><div> [if | guard...else](3) someCondition(4) {</div><div> [continue | break](5)</div><div> }</div><div> }</div><div><br></div><div>I have to be more careful now interpreting the meaning of this loop because both or either of if/guard or continue/break can invert its meaning, where was "for-in-where" is concise and clear.</div></div></div></blockquote><div><br></div><div>I like this way of thinking a lot, actually. Number of divergent constructs you have to parse. Here's the thing: I think it supports removal, not retaining. Here's why:</div><div><br></div><div>For every loop you encounter, to understand its meaning you *must* look for `break` and `continue` statements, and when they're inside `if` and `guard` you must consider how the condition is evaluated. This is a given, a sunk cost; I see no way they can be prohibited from the language, so these are all things you will have to look for and mentally parse in order to understand the behavior of a loop.</div><div><br></div><div>Now, if you add `where`, then that is one additional divergent construct you must understand and parse. And moreover, since you know it exists, to be sure you really understand what's going on you'll have to check the end of every `for...in` statement to see if it's there. And in case the line doesn't fit on your screen, you'll have to try scrolling to see if there's more (or read on to the next line if you've turned on line wrapping). And you'll have to do this for *every* `for...in` loop, where the majority don't use `where` at all!</div><div><br></div><div>So, I agree with you, what's important to me as well is number of divergent constructs I have to parse. But with the removal of `where`, the number of divergent constructs I have to think about while reading Swift loops will decrease, not increase.</div><div><br></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_quote"><div>Doing .lazy.filter{...} is slightly cleaner than this, but still suffers from the disadvantage that it's very easy for newcomers to leave out the "lazy" part and accidentally write poorly performing code, and to the argument that "where" is considered confusing by some users, I would argue that it's easier to explain how it works than why "lazy" is necessary in this context.</div><span class=""><div> </div><div><br></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><br></div></div></div></div>
_______________________________________________<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>
</blockquote></span></div></div>
</blockquote></div><br></div></div>