<div dir="ltr">On Fri, Jun 24, 2016 at 1:38 PM, Tony Allevato <span dir="ltr">&lt;<a href="mailto:allevato@google.com" target="_blank">allevato@google.com</a>&gt;</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 &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; 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">&lt;<a href="mailto:wjs@mac.com" target="_blank">wjs@mac.com</a>&gt;</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 &lt;<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>&gt; 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&#39;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 &quot;to each their own&quot; is that Swift&#39;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 &quot;<span style="font-size:13px">understand as much as possible about the control flow of the loop from a single line of code,&quot; then we ought perhaps to question its appropriateness when the majority of its benefits [by which I mean, based on your examples and Sean&#39;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&#39;t be talking about &quot;a single line of code&quot; so much as &quot;a single cohesive construct&quot;. What&#39;s important to me isn&#39;t the line length or whether the &quot;where&quot; part has to wrap onto another line, it&#39;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 &quot;for-in-where&quot;, it&#39;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&#39;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 &quot;for-in-where&quot; is concise and clear.</div></div></div></blockquote><div><br></div><div>And if `while` is added along with `where`, all this goes out the window.</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_quote"><div>Doing .lazy.filter{...} is slightly cleaner than this, but still suffers from the disadvantage that it&#39;s very easy for newcomers to leave out the &quot;lazy&quot; part and accidentally write poorly performing code, and to the argument that &quot;where&quot; is considered confusing by some users, I would argue that it&#39;s easier to explain how it works than why &quot;lazy&quot; is necessary in this context.</div></div></div></blockquote><div><br></div><div>Clearly, eagerly filtering results in slower code, but based on the examples provided above I don&#39;t imagine any of them would turn into &quot;poorly performing&quot; code with eager filtering. In fact, I see some that could run a little faster with some refactoring along these lines. In any case, optimizing performance comes after correctness; a user who can&#39;t grasp `lazy` can nonetheless still write useful, correct code.</div><div><br></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_quote"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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>