<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">I think this is an excellent argument for keeping <font face="Menlo" class="">where</font> — I was tempted to make a hand waving argument in favor of keeping <font face="Menlo" class="">where</font>, but I think you made the case as well as it can be made. (I suppose you could even argue that there are really 7 components to the other construct since you can have continue, break, or return, but that just underscores your point.)<div class=""><br class=""></div><div class="">I also agree with your points about using lazy.filter instead.</div><div class=""><br class=""></div><div class="">BTW, the project I’m currently working on has about 10-15 for loops that use where.</div><div class=""><br class=""></div><div class="">Net/net: I’m a -1 on the proposal.</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jun 24, 2016, at 11:38 AM, Tony Allevato via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><div class=""><div dir="ltr" class=""><div class="gmail_quote"><div dir="ltr" class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">With "for-in-where", it's three:</div><div class=""><br class=""></div><div class=""> for item(1) in someCollection(2) where someCondition(3)</div><div class=""><br class=""></div><div class="">With the alternatives suggested using if/guard/continue/break, it's more than that:</div><div class=""><br class=""></div><div class=""> for item(1) in someCollection(2) {</div><div class=""> [if | guard...else](3) someCondition(4) {</div><div class=""> [continue | break](5)</div><div class=""> }</div><div class=""> }</div><div class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">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><div class=""> </div><div class=""><br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""><br class=""></div></div></div></div>
_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
</blockquote></div></div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></div></body></html>