<div dir="ltr">On Fri, Jun 10, 2016 at 7:18 AM, Haravikk <span dir="ltr">&lt;<a href="mailto:swift-evolution@haravikk.me" target="_blank">swift-evolution@haravikk.me</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"><br><div><span class=""><blockquote type="cite"><div>On 10 Jun 2016, at 07:25, Xiaodi Wu via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:</div><div><div dir="ltr" style="font-family:Helvetica;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"><div class="gmail_extra"><div class="gmail_quote"><div>* Swift is explicitly a C-family language. In most or all other C-family languages, for loop statements allow specification of conditions for exiting the loop but not for filtering. Therefore, Swift&#39;s use of `where` is unprecedented and needs to be learned anew by every user of Swift.</div></div></div></div></div></blockquote><div><br></div></span><div>Swift may have some similarities with C, but the last thing anyone should want is for it to be bound to C as a language.</div></div></div></blockquote><div><br></div><div>That&#39;s not my argument at all. There are elements of syntax that are commonly seen in languages that take inspiration from C. We can rightly say that those are &#39;familiar&#39; or &#39;precedented,&#39; by which I mean that a significant proportion of people who come to Swift will be familiar with how they work. This is a consideration, though by no means determinative of what features we should have.</div><div><br></div><div>By contrast, there are elements of syntax in Swift which are &#39;unprecedented.&#39; Some of those support features unique to Swift, or features that Swift deliberately makes more prominent--take, for example, sugar for unwrapping optionals or a greatly expanded type system.</div><div><br></div><div>We have heard from the core team that the `where` clause was put into the language in order to align with greatly expanded pattern matching facilities, but this was abandoned. Thus it now falls into a second category of &#39;unprecedented&#39; syntax: a syntax with no parallels in other languages that take inspiration from C, but which does not serve a purpose that is unique to or uniquely emphasized in Swift.</div><div><br></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><div>Besides, the purpose of a for in loop is to iterate over elements in a sequence, so filtering is very much a useful thing to do so it’s hardly unprecedented, and it’s also a fairly common thing to want to do.</div></div></div></blockquote><div><br></div><div>That&#39;s not what I mean by precedent--see above.</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><span class=""><br><blockquote type="cite"><div><div dir="ltr" style="font-family:Helvetica;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"><div class="gmail_extra"><div class="gmail_quote"><div>* The word &quot;where&quot; does not consistently imply `break` or `continue`. In current Swift, `where` implies `break` in the context of a `while` loop and `continue` in the context of a `for` loop. Some users intuitively guess the correct meaning in each context, while others guess the wrong meaning. Therefore, the only way to learn for sure what `where` means in any context is to read the rulebook. That, by definition, means that this is unintuitive.</div></div></div></div></div></blockquote><div><br></div></span><div>This is an argument for renaming the where keyword on for loops to be more clear, or to somehow integrate continue/break to be more explicit about what the developer intends for it to do.</div></div></div></blockquote><div><br></div><div>Sure: I conclude that the keyword should be *either* removed *or* reformed; both outcomes could address the issue.</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><span class=""><br><blockquote type="cite"><div><div dir="ltr" style="font-family:Helvetica;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"><div class="gmail_extra"><div class="gmail_quote"><div>* There are other ways to break from a loop or continue to the next iteration without performance penalty. Nearly all of these serve more general purposes than a `where` clause. </div></div></div></div></div></blockquote><div><br></div></span><div>This isn’t really an argument against the where clause; the where clause is useful for common, simple cases, so it’s not surprising if more complex/unusual cases can’t (or can’t easily) be handled by it. This is for the simple cases where this isn’t an issue.</div><span class=""><div><br></div><blockquote type="cite"><div><div dir="ltr" style="font-family:Helvetica;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"><div class="gmail_extra"><div class="gmail_quote"><div>Some of these (such as `if` or `guard`) would already be familiar to a new user before they encounter loops, assuming a typical order for learning a programming language. Many of these (such as filtering methods on collections, or simply `if`) would be familiar to a user of another C-family language. Therefore, the `where` clause provides no independent utility, is not more discoverable than its alternatives, and is not required for progressive disclosure of an important facility to a learner (i.e. a simplified syntax for those who may not be ready for the advanced concepts needed to use a more fully-featured alternative).</div></div></div></div></div></blockquote><div><br></div></span><div>Simplification isn’t just for the new users; all you need to know with where is that it’s a shorthand for guard X else { continue }, for many people this is intuitive enough, but if there are enough for whom it isn’t then again that’s an argument to tweak it to be more clear about what it does, rather than remove it entirely.</div><div><br></div><div>The independent utility that it offers is being able to avoid if/guard boilerplate at the start of your loop, but instead putting it on the same line; in simple cases this can be nice and neat.</div></div></div></blockquote><div><br></div><div>That is not at all &#39;utility.&#39; It is tautologically true that if you have two alternatives A and B, using A has the &#39;utility&#39; that you don&#39;t have to use B. And since the whole point here is that the word `break` or `continue` is not implied by `where`, I argue that writing it out within a `guard` statement isn&#39;t boilerplate but absolutely essential. By contrast, I have argued that the `where` syntax is not &#39;nice&#39; or &#39;neat.&#39;</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><span class=""><div><br></div><blockquote type="cite"><div><div dir="ltr" style="font-family:Helvetica;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"><div class="gmail_extra"><div class="gmail_quote"><div>it has been used incorrectly by at least some users.</div></div></div></div></div></blockquote><div><br></div></span><div>Every feature in every language &quot;has been used incorrectly by at least some users&quot;, should we just drop all programming languages?</div></div></div></blockquote><div><br></div><div>Not every feature serves no independent purpose *and* is used incorrectly by at least some users.</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><div>It’s not as if users can’t make mistakes while using an inline if/guard condition.</div></div></div></blockquote><div><br></div><div>One that&#39;s not caught at compile time? Show me.</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><div>Again, this an argument that the meaning isn’t implicit enough, which is just as well served by tweaking the syntax than removing it.</div></div></div></blockquote><div><br></div><div>Again, I&#39;d be happy tweaking the syntax to make it clear, if possible. If not, I&#39;d remove it. </div></div><br></div></div>