<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>They would differ in, what at least to me, seems pretty logical ways:</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature"><blockquote type="cite"><blockquote type="cite"><font color="#000000"><span style="background-color: rgba(255, 255, 255, 0);">while !stopped for unit in workToDo where unit.passesTest(condition) { unit.process() }</span></font></blockquote></blockquote><br></div><div id="AppleMailSignature">Would be:</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">while !stopped {</div><div id="AppleMailSignature"><span style="background-color: rgba(255, 255, 255, 0);">&nbsp; for unit in workToDo where unit.passesTest(condition) {</span></div><div id="AppleMailSignature"><span style="background-color: rgba(255, 255, 255, 0);">&nbsp; &nbsp; unit.process()</span></div><div id="AppleMailSignature"><span style="background-color: rgba(255, 255, 255, 0);">&nbsp; }</span></div><div id="AppleMailSignature"><span style="background-color: rgba(255, 255, 255, 0);">}</span></div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature"><blockquote type="cite"><blockquote type="cite"><font color="#000000"><span style="background-color: rgba(255, 255, 255, 0);">for unit in workToDo while !stopped where unit.passesTest(condition) { unit.process() }</span></font></blockquote></blockquote></div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">Would be:</div><div id="AppleMailSignature"><span style="background-color: rgba(255, 255, 255, 0);"><br></span></div><div id="AppleMailSignature"><span style="background-color: rgba(255, 255, 255, 0);">for unit in workToDo {</span></div><div id="AppleMailSignature"><span style="background-color: rgba(255, 255, 255, 0);">&nbsp; guard !stopped else { break }</span></div><div id="AppleMailSignature"><span style="background-color: rgba(255, 255, 255, 0);">&nbsp; If unit.passesTest(condition) { unit.process() }</span></div><div id="AppleMailSignature">}</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">This would likely read even better if "where" was woven into the for:</div><div id="AppleMailSignature"><span style="background-color: rgba(255, 255, 255, 0);"><br></span></div><div id="AppleMailSignature"><span style="background-color: rgba(255, 255, 255, 0);">for unit&nbsp;where unit.passesTest(condition)&nbsp;in workToDo while !stopped { unit.process() }</span></div><div id="AppleMailSignature"><span style="background-color: rgba(255, 255, 255, 0);"><br></span></div><div id="AppleMailSignature"><span style="background-color: rgba(255, 255, 255, 0);">Or possibly reformatted to something like:</span></div><div id="AppleMailSignature"><span style="background-color: rgba(255, 255, 255, 0);"><br></span></div><div id="AppleMailSignature"><div id="AppleMailSignature"><span style="background-color: rgba(255, 255, 255, 0);">for&nbsp;</span><span style="background-color: rgba(255, 255, 255, 0);">unit</span></div><div id="AppleMailSignature"><span style="background-color: rgba(255, 255, 255, 0);">&nbsp; where unit.passesTest(condition)</span></div><div id="AppleMailSignature"><span style="background-color: rgba(255, 255, 255, 0);">&nbsp; in workToDo</span></div><div id="AppleMailSignature"><span style="background-color: rgba(255, 255, 255, 0);">&nbsp; while !stopped</span></div><div id="AppleMailSignature"><span style="background-color: rgba(255, 255, 255, 0);">{&nbsp;</span><span style="background-color: rgba(255, 255, 255, 0);">unit.process()&nbsp;</span><span style="background-color: rgba(255, 255, 255, 0);">}</span></div></div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">l8r</div><div id="AppleMailSignature">Sean<br><br>Sent from my iPad</div><div><br>On Jun 8, 2016, at 5:42 PM, Tim Vermeulen &lt;<a href="mailto:tvermeulen@me.com">tvermeulen@me.com</a>&gt; wrote:<br><br></div><blockquote type="cite"><div><span>I’m not sure I follow, how would the two be different?</span><br><span></span><br><blockquote type="cite"><span>There might be value in entertaining the idea of unifying constructs such that they all allow arbitrary combinations of for/while/where/etc.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Such as:</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>while !stopped for unit in workToDo where unit.passesTest(condition) { unit.process() }</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Which would mean something different than:</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>for unit in workToDo while !stopped where unit.passesTest(condition) { unit.process() }</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>And yes, they are very similar visually but differ subtly in meaning, but the same can be said about different sentences in english that might all share the same words and differ only by their order. It’s not exactly a foreign concept! I don’t know of any languages that are quite so expressive as that might be. Are there advantages to something more outlandish like this? I don’t know. I’m not proposing it directly, just thinking out loud, I guess.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>l8r</span><br></blockquote><blockquote type="cite"><span>Sean</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>On Jun 8, 2016, at 4:44 PM, Haravikk via swift-evolution&lt;<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt;wrote:</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>On 8 Jun 2016, at 17:11, Xiaodi Wu&lt;<a href="mailto:xiaodi.wu@gmail.com">xiaodi.wu@gmail.com</a>&gt;wrote:</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>On Wed, Jun 8, 2016 at 3:38 AM, Haravikk&lt;<a href="mailto:swift-evolution@haravikk.me">swift-evolution@haravikk.me</a>&gt;wrote:</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>Yes this could be handled by an if/guard statement with continue, and while as proposed here could be done with the same plus a break, but these things come up so often that it just makes a lot of sense to get it all neatly onto one line.</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>As I pointed out above with Tim's example, putting it all on one line is absolutely not 'neat'--it reads like spaghetti. That is one major beef I have with this proposal: that it *encourages* writing on one line too many things that, whether you use `where` or not, are much more clearly written on multiple lines. If writing everything on one line is for you the major advantage of this proposal, we could agree on everything else and I would be very much opposed to this proposal on that basis alone.</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>I’m not proposing that every single loop have all of its conditions crushed onto one line, just like I wasn’t when discussing where on the condition clause thread. The usefulness of where and the proposed while is in the common, simple cases, for example:</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>for eachValue in theValues while eachValue&lt;100 where eachValue % 2 == 0 { … }</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>The alternatives would be:</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>for eachValue in theValues {</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>guard eachValue&lt;100 else { break }</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>guard eachValue % 2 == 0 else { continue }</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>…</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>}</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>for eachValue in theValues.prefix(while: { $0&lt;100 }).filter({ $0 % 2 == 0 }) { … } // Could also be on multiple lines</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>The former wastes vertical space for what it does IMO; it’s fine if the conditions were more complicated, but since they’re not where/while is ideal. The second isn’t terrible, but it’s a pretty noisy way to handle common loop conditions.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>The use of where/while isn’t about eliminating either of these alternatives, they’re absolutely useful in cases where their drawbacks become advantages. For example the inline guards are great when the conditions are more complex, and necessary if you want to do more than the simple cases allow. The second form is best when you need more than the two methods, alternate methods, or you have predicates you can pass in directly, although personally when I do this I tend to do the chinning on its own lines outside of the loop, leaving me with a loop of: for eachValue in theFilteredValues { … } or whatever.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>Closures are--I'm sure you'd agree--a far more advanced concept than loops. Concepts like closing over a variable are very, very hard. Many useful things can be written without using closures. Not so many things could do without loops. It very much matters that a learner might feel that he or she cannot understand everything about a loop with the handwavy explanation that it'll "come later”.</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Not my point at all; my point was about the shorthand for closures not closure as a whole, you can’t learn the closure shorthands without first learning what a closure is. In exactly the same way where/while are just be shorthands for inline if/guard, you don’t need to learn about these clauses to make a functioning loop if you know how to do it with your if/guard statements. In fact it’s better to learn it in this order as once you know what each clause is a shorthand form of (if/guard continue or break) then you know exactly what it does already.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Ignoring for a moment that you’re opposed to the where clause in general, what would your thoughts be on only permitting one of where/while in a for? i.e- you would be able to do only one of:</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>for eachValue in theValues where eachValue % 2 == 0 { … }</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>for eachValue in theValues while eachValue&lt;100 { … }</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>But not have both a where and a while on the same line. This eliminates the question mark around the order they are applied in, while still giving us the ability to essentially switch the behaviour of the where from continue to break. I’m not decided whether I want both in a single statement or if I just want to be able to choose between them. It also limits how much goes on one line as you have to use an inline condition to achieve both for a single loop.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>_______________________________________________</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>swift-evolution mailing list</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span></span></blockquote></div></blockquote></body></html>