<div dir="ltr">On Fri, Jun 10, 2016 at 9:25 PM, Jonathan Hull <span dir="ltr">&lt;<a href="mailto:jhull@gbis.com" target="_blank">jhull@gbis.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 style="word-wrap:break-word"><div>Please leave this feature in!</div><div><br></div><div>One of the places I get bitten the most during refactoring is somehow missing a ‘continue’ statement inside the loop (and I hear that is a common issue).  For-in-where lets me guard against that problem in simple cases.  </div></div></blockquote><div><br></div><div>Hmm, that&#39;s an interesting use case. That said, the simple case that could get replaced by `where` is an opening `guard` statement, precisely one that you wouldn&#39;t somehow miss. The ones you&#39;ll get bitten by, you&#39;ll still get bitten by whatever way this goes...</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>I also find that it is often the clearest way to capture the semantics of what I want.  I find it extremely readable and compact. Everything is all in one place :-)<br></div><div><br></div><div>As for the issue of “dialects”, it really just feels like people are trying to force their particular pet coding style on everyone else.</div></div></blockquote><div><br></div><div>Not at all (at least not from me). We find `while` to be problematic for the reasons outlined in the draft proposal, not for reasons of style. On the contrary, it&#39;s the advocates for keeping `while` that argue that it&#39;s good style. (Which I dispute, but which is not the reason for the proposal.)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>Should we get rid of .forEach() as well?  Sometimes languages have more than one way to do something, and it is up to the programmer to pick the form that is clearest in the context of use...</div><div><br></div><div>Thanks,</div><div>Jon</div><div><br></div><div><blockquote type="cite"><pre style="white-space:pre-wrap;background-color:rgb(255,255,255)">I respect that anti-goal, but I think being over-rigid about limiting
developers&#39; choice of expression is also an anti-goal.

To me, it is like guard statements vs. if-let statements. Some people find
one to be more clear than the other. Often times the best choice depends on
the context. Sometimes a guard statement can be re-written as an if-let
statement in a way that makes the code more clear, and vice versa. And
different people will inevitably have different personal preferences -
their own &quot;style&quot;, if you will - and will favor one over the other. But it
would be a mistake to force everyone into one box in order to prevent the
fracturing of the Swift community into &quot;dialects.&quot;

But most importantly (and this is really the kicker for me) there are times
when the &quot;where&quot; syntax provides the maximum amount of clarity in the
context of my code, and I don&#39;t want to lose that expressive power.</pre></blockquote><span class=""><div><blockquote type="cite"><pre style="white-space:pre-wrap;background-color:rgb(255,255,255)"><blockquote type="cite">On Fri, Jun 10, 2016 at 10:17 AM Xiaodi Wu &lt;<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">xiaodi.wu at gmail.com</a>&gt; wrote:

&gt;<i> I think this idea--if you don&#39;t like it, then you don&#39;t have to use it--is
</i>&gt;<i> indicative of a key worry here: it&#39;s inessential to the language and
</i>&gt;<i> promotes dialects wherein certain people use it and others wherein they
</i>&gt;<i> don&#39;t. This is an anti-goal.</i></blockquote></pre></blockquote><div><br></div></div></span></div></div></blockquote></div><br></div></div>