<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Jun 11, 2016 at 5:03 PM, Thorsten Seitz <span dir="ltr"><<a href="mailto:tseitz42@icloud.com" target="_blank">tseitz42@icloud.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div><div class="h5"><div></div><div><br></div><div><br>Am 11.06.2016 um 23:45 schrieb Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>>:<br><br></div><blockquote type="cite"><div><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jun 11, 2016 at 3:37 PM, Thorsten Seitz <span dir="ltr"><<a href="mailto:tseitz42@icloud.com" target="_blank">tseitz42@icloud.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div><div><div></div><div><br></div><div><br>Am 11.06.2016 um 22:29 schrieb L. Mihalkovic <<a href="mailto:laurent.mihalkovic@gmail.com" target="_blank">laurent.mihalkovic@gmail.com</a>>:<br><br></div><blockquote type="cite"><div><div><br></div><div><br>On Jun 11, 2016, at 9:53 PM, Thorsten Seitz via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><div></div><div><br></div><div><br>Am 10.06.2016 um 18:28 schrieb Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>>:<br><br></div><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Jun 10, 2016 at 6:10 AM, Karl <span dir="ltr"><<a href="mailto:razielim@gmail.com" target="_blank">razielim@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div>-1</div><span><div><br><blockquote type="cite"><div dir="ltr"><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's use of `where` is unprecedented and needs to be learned anew by every user of Swift.</div></div></div></div></blockquote><br></div></span><div>When was this decided? I distinctly remember some bloke under Craig Federighi’s hair saying that it was time to “move beyond” C and essentially ditch legacy conventions which no longer make sense.</div></div></blockquote><div><br></div><div>I think you misunderstood my argument here. I don't mean that we should yoke ourselves to C conventions, and we should absolutely ditch C convention when it doesn't make sense. The big-picture argument here is that `where` doesn't pass the bar of correcting a C convention that no longer makes sense.</div><div><br></div><div>FWIW, on the topic of syntax choices, here is what Chris Lattner had to say on this list:</div><div><br></div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">Kevin got it exa<b style="background-color:rgb(255,255,102)">c</b>tly right, but I’d expand that last bit a bit to:<br>
“… pi<b style="background-color:rgb(255,255,102)">c</b>king the one that is most familiar to programmers in the extended <b style="background-color:rgb(255,255,102)">C</b> <b style="background-color:rgb(255,255,102)">family</b> is a good idea.["]<br>
The extended <b style="background-color:rgb(255,255,102)">C</b> <b style="background-color:rgb(255,255,102)">family</b> of language (whi<b style="background-color:rgb(255,255,102)">c</b>h in<b style="background-color:rgb(255,255,102)">c</b>ludes <b style="background-color:rgb(255,255,102)">C</b>, <b style="background-color:rgb(255,255,102)">C</b>++, Obj<b style="background-color:rgb(255,255,102)">C</b>, but also <b style="background-color:rgb(255,255,102)">C</b>#, Java, Javas<b style="background-color:rgb(255,255,102)">c</b>ript, and more) is<br>an extremely popular and widely used set of languages that have a lot of surfa<b style="background-color:rgb(255,255,102)">c</b>e-level similarity. I<br>don’t <b style="background-color:rgb(255,255,102)">c</b>laim to know the design rationale of all of these languages, but I surmise that this is not an<br>a<b style="background-color:rgb(255,255,102)">c</b><b style="background-color:rgb(255,255,102)">c</b>ident: programmers move around and work in different languages, and this allows a non-expert in the<br>language to understand what is going on. While there are things about <b style="background-color:rgb(255,255,102)">C</b> that are really unfortunate IMO<br>(e.g. the de<b style="background-color:rgb(255,255,102)">c</b>larator/de<b style="background-color:rgb(255,255,102)">c</b>laration spe<b style="background-color:rgb(255,255,102)">c</b>ifier part of the grammar) there is a lot of goodness in the basi<b style="background-color:rgb(255,255,102)">c<br></b>operator set, fo<b style="background-color:rgb(255,255,102)">c</b>us on dot syntax, and more.<br>
I do agree that there are some benefits to dit<b style="background-color:rgb(255,255,102)">c</b>hing bra<b style="background-color:rgb(255,255,102)">c</b>es and relying on indentation instead, but there are<br>also downsides. Deviating from the <b style="background-color:rgb(255,255,102)">C</b> <b style="background-color:rgb(255,255,102)">family</b> in this respe<b style="background-color:rgb(255,255,102)">c</b>t would have to provide <b>*overwhelmingly*</b> large <br><span style="color:rgb(0,0,0)">advantages for us to take su</span><b style="color:rgb(0,0,0);background-color:rgb(255,255,102)">c</b><span style="color:rgb(0,0,0)">h a plunge, and they simply don’t exist.</span></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div>As I understand it, Swift is a new language with new conventions. It is desirable to align as many of those as possible with existing conventions so as to be easily learned, but if you limit Swift to other languages conventions you deny it any identity. Did Python ask anybody’s opinion before dropping curly-braces? Did people learn whatever Perl is supposed to be? Look at C’s hieroglyphic for loops! </div></div></blockquote><div><br></div><div>I don't think we disagree here.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><br></div><div>Realistically, “for … in … while” is not going to cause incredible confusion. Removing it would cause a lot of frustration. You can’t on the one hand say our users are comfortable with the axioms of C’s hieroglyphic loops, and on the other hand say “for x in y while" is confusing.</div><span><div><br></div><div><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Again, as I said, once you've mastered something, by definition you find it not confusing. Why should we doom x% of new users to writing a loop incorrectly at least once when we don't have to?</div></div></div></div></blockquote></div></span><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>Ah, but if you’re not “doomed” to failing once, how will you ever master anything? Nobody knew how to write a C for-loop until someone showed them (and even then…). Nobody is going to just open a REPL and start writing code, with zero prior understanding of what Swift syntax looks like.</div></div></div></div></div></div></blockquote><div><br></div><div>The thought here is along the lines of what Chris said, quoted above, and repeated here: "The extended C family of language [...] is an extremely popular and widely used set[;] programmers move around and work in different languages, and [aligning to expectations arising from other C family languages] allows a non-expert in the language to understand what is going on." By contrast, the `where` clause violates that expectation and I do not see "overwhelmingly large advantages" for doing so.</div></div></div></div></div></blockquote><div><br></div>What about C#'s `where` then? As C# is a member of the C family languages `where` is not violating expectations!</div></blockquote><div><br></div><div>Where is not exactly a part of c# it belongs to linq</div></div></blockquote><div><br></div></div></div>And that is not a part of C#??</div></blockquote><div><br></div><div>SQL is a domain-specific language, and LINQ is an internal domain-specific language with a language extension for C#. Neither is a general purpose language.<br></div></div></div></div></div></blockquote><div><br></div></div></div>I don't see how that is relevant especially given the prominence and reach of SQL (which is turing complete, btw ;-)</div></blockquote><div><br></div><div>It is relevant because the design of every language has to contend with trade-offs, and the trade-offs that make `where` a powerful and intuitive keyword in the context of a query language are different from the tradeoffs we must contend with in a general purpose language. HTML+CSS has also been proved Turing-complete; it is irrelevant to the question of whether the idioms of HTML+CSS are appropriate in a general purpose language.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div><span class=""><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Your example actually goes to one of Laurent's points. Should the Swift core team or an enterprising community member propose a set of similarly powerful tools, along with a set of language extensions that add syntactic sugar for them, I (and I think Laurent, if I understand him correctly) would absolutely be in favor of such an addition. But as it is, `where` is an odd duckling. Just as you say, it looks like a component of a query language, but it does no such thing. In a for loop, it does some filtering, but until recently it functioned like a comma in `while` loops. Look at those other keywords which make this sugar possible in C#: in your example, `from` and `select`. We don't have any of that intrastructure in Swift.</div></div></div></div></div></blockquote><div><br></div></span>We can simply extend the for-in-where loop for that like Scala does. No need to add new syntax if an existing one can simply be generalized.</div></div></blockquote><div><br></div><div>If you want to propose adopting Scala's `if`, you are free to start a discussion on that topic. Note how Scala also avoids use of the word `where`.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><span class="HOEnZb"><font color="#888888"><div><br></div><div>-Thorsten </div></font></span><span class=""><div><br></div><div><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div>The following is an example from MSDN with `where` clearly beaing a keyword:</div><div><br><div><pre style="padding:5px;margin-top:0px;margin-bottom:0px;overflow:auto;word-wrap:normal"><font face="UICTFontTextStyleTallBody"><span style="white-space:normal;background-color:rgba(255,255,255,0)"><b>var</b> numQuery =
<b>from</b> num <b>in</b> numbers
<b>where</b> (num % 2) == 0
<b>select</b> num;</span></font><span style="font-size:13px;font-family:Consolas,Courier,monospace!important">
</span></pre><div><br></div><div>-Thorsten </div><blockquote type="cite"><div><div></div></div></blockquote></div></div></div></blockquote></div><br></div></div>
</div></blockquote></div></span></div></blockquote></div><br></div></div>