<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=""><br class=""><div><blockquote type="cite" class=""><div class="">Am 12.06.2016 um 12:02 schrieb L Mihalkovic <<a href="mailto:laurent.mihalkovic@gmail.com" class="">laurent.mihalkovic@gmail.com</a>>:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jun 11, 2016, at 11:45 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" class="">xiaodi.wu@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><br class="Apple-interchange-newline"><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class="gmail_quote" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">On Sat, Jun 11, 2016 at 3:37 PM, Thorsten Seitz<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:tseitz42@icloud.com" target="_blank" class="">tseitz42@icloud.com</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div dir="auto" class=""><div class=""><div class="h5"><div class=""></div><div class=""><br class=""></div><div class=""><br class="">Am 11.06.2016 um 22:29 schrieb L. Mihalkovic <<a href="mailto:laurent.mihalkovic@gmail.com" target="_blank" class="">laurent.mihalkovic@gmail.com</a>>:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div class=""><br class=""></div><div class=""><br class="">On Jun 11, 2016, at 9:53 PM, Thorsten Seitz via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div class=""></div><div class=""><br class=""></div><div class=""><br class="">Am 10.06.2016 um 18:28 schrieb Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>>:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote">On Fri, Jun 10, 2016 at 6:10 AM, Karl<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:razielim@gmail.com" target="_blank" class="">razielim@gmail.com</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div style="word-wrap: break-word;" class=""><div class="">-1</div><span class=""><div class=""><br class=""><blockquote type="cite" class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">* 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 class=""></div></span><div class="">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 class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">FWIW, on the topic of syntax choices, here is what Chris Lattner had to say on this list:</div><div class=""><br class=""></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;">Kevin got it exa<b style="background-color: rgb(255, 255, 102);" class="">c</b>tly right, but I’d expand that last bit a bit to:<br class="">“… pi<b style="background-color: rgb(255, 255, 102);" class="">c</b>king the one that is most familiar to programmers in the extended<span class="Apple-converted-space"> </span><b style="background-color: rgb(255, 255, 102);" class="">C</b><span class="Apple-converted-space"> </span><b style="background-color: rgb(255, 255, 102);" class="">family</b><span class="Apple-converted-space"> </span>is a good idea.["]<br class="">The extended<span class="Apple-converted-space"> </span><b style="background-color: rgb(255, 255, 102);" class="">C</b><span class="Apple-converted-space"> </span><b style="background-color: rgb(255, 255, 102);" class="">family</b><span class="Apple-converted-space"> </span>of language (whi<b style="background-color: rgb(255, 255, 102);" class="">c</b>h in<b style="background-color: rgb(255, 255, 102);" class="">c</b>ludes<span class="Apple-converted-space"> </span><b style="background-color: rgb(255, 255, 102);" class="">C</b>,<span class="Apple-converted-space"> </span><b style="background-color: rgb(255, 255, 102);" class="">C</b>++, Obj<b style="background-color: rgb(255, 255, 102);" class="">C</b>, but also<span class="Apple-converted-space"> </span><b style="background-color: rgb(255, 255, 102);" class="">C</b>#, Java, Javas<b style="background-color: rgb(255, 255, 102);" class="">c</b>ript, and more) is<br class="">an extremely popular and widely used set of languages that have a lot of surfa<b style="background-color: rgb(255, 255, 102);" class="">c</b>e-level similarity. I<br class="">don’t<span class="Apple-converted-space"> </span><b style="background-color: rgb(255, 255, 102);" class="">c</b>laim to know the design rationale of all of these languages, but I surmise that this is not an<br class="">a<b style="background-color: rgb(255, 255, 102);" class="">c</b><b style="background-color: rgb(255, 255, 102);" class="">c</b>ident: programmers move around and work in different languages, and this allows a non-expert in the<br class="">language to understand what is going on. While there are things about<span class="Apple-converted-space"> </span><b style="background-color: rgb(255, 255, 102);" class="">C</b><span class="Apple-converted-space"> </span>that are really unfortunate IMO<br class="">(e.g. the de<b style="background-color: rgb(255, 255, 102);" class="">c</b>larator/de<b style="background-color: rgb(255, 255, 102);" class="">c</b>laration spe<b style="background-color: rgb(255, 255, 102);" class="">c</b>ifier part of the grammar) there is a lot of goodness in the basi<b style="background-color: rgb(255, 255, 102);" class="">c<br class=""></b>operator set, fo<b style="background-color: rgb(255, 255, 102);" class="">c</b>us on dot syntax, and more.<br class="">I do agree that there are some benefits to dit<b style="background-color: rgb(255, 255, 102);" class="">c</b>hing bra<b style="background-color: rgb(255, 255, 102);" class="">c</b>es and relying on indentation instead, but there are<br class="">also downsides. Deviating from the<span class="Apple-converted-space"> </span><b style="background-color: rgb(255, 255, 102);" class="">C</b><span class="Apple-converted-space"> </span><b style="background-color: rgb(255, 255, 102);" class="">family</b><span class="Apple-converted-space"> </span>in this respe<b style="background-color: rgb(255, 255, 102);" class="">c</b>t would have to provide<span class="Apple-converted-space"> </span><b class="">*overwhelmingly*</b><span class="Apple-converted-space"> </span>large <br class=""><span style="" class="">advantages for us to take su</span><b style="background-color: rgb(255, 255, 102);" class="">c</b><span style="" class="">h a plunge, and they simply don’t exist.</span></blockquote><div class=""> </div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div style="word-wrap: break-word;" class=""><div class="">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 class=""><br class=""></div><div class="">I don't think we disagree here.</div><div class=""> </div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div style="word-wrap: break-word;" class=""><div class=""><br class=""></div><div class="">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 class=""><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">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 class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">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 class=""><br class=""></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 class=""><br class=""></div><div class="">Where is not exactly a part of c# it belongs to linq</div></div></blockquote><div class=""><br class=""></div></div></div>And that is not a part of C#??</div></blockquote><div class=""><br class=""></div><div class="">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 class=""></div><div class=""><br class=""></div><div class="">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 class=""> </div></div></div></blockquote><div class=""><br class=""></div><div class="">IMHO the team has taken an Ockham Axe to the grammar: in the presence of multiple ways to produce the same or an acceptable stand-in (for eg when the only difference is an acceptable temporary perf setback), then the solution requiring the least assumptions on the compiler wins. </div><div class=""><br class=""></div><div class="">I would even extend this rule with the corollary that between an assumption materialized as a type checker rule and an assumption materialized as a full blown extra language keyword, there might be a bias to accept the former if it kills the latter. But this is just my personal inference of what their decision heuristic might be based solely on what I saw. My sole interest in trying to understand their decision making process is to try to avoid proposals that have little to no chance to go anywhere, as well as trying to present ones that will align better with where the language is going.</div><div class=""><br class=""></div><div class="">In this instance, WHERE is a heavy assumption on the compiler for no greater gain than filters can provide. So I think we save the WHERE keyword for an outcome that will be really worth it! Something along the idea of Linq, but with a proper Swift feel to it. What does it look like? I cannot say yet. But the good news is that having taken WHERE out now will make that next step a purely additive process (nothing will be taken out then, but a big thing will be gained). </div></div></div></div></blockquote><div><br class=""></div>I am all for extending `for` to be more like Scala’s `for`-expression or Haskell’s `do`-notation. LINQ might be too focused on querying.</div><div>Extending the current `where` to be syntax sugar for `filter` would be quite straightforward, though, so I’m not sure whether removing it first is really necessary. </div><div>That was not object of the pitch to retire `where` from `for`-loops, though. Instead the argument was (and still is) that `where` might be misunderstood there by beginners and should therefore be removed. This argument would apply to an extended `where` unchanged, because I can still write the exact same code as being criticized now and can even do more complicated things which would by even more hard to understand for beginners.</div><div>That’s the argument I disagree with.</div><div><br class=""></div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class=""><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div class="gmail_quote" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div dir="auto" class=""><div class="">The following is an example from MSDN with `where` clearly beaing a keyword:</div><div class=""><br class=""><div class=""><pre style="padding: 5px; margin-top: 0px; margin-bottom: 0px; overflow: auto; word-wrap: normal;" class=""><font face="UICTFontTextStyleTallBody" class=""><span style="white-space: normal; background-color: rgba(255, 255, 255, 0);" class=""><b class="">var</b><span class="Apple-converted-space"> </span>numQuery =<span class="Apple-converted-space"> </span><b class="">from</b><span class="Apple-converted-space"> </span>num<span class="Apple-converted-space"> </span><b class="">in</b><span class="Apple-converted-space"> </span>numbers<span class="Apple-converted-space"> </span><b class="">where</b><span class="Apple-converted-space"> </span>(num % 2) == 0<span class="Apple-converted-space"> </span><b class="">select</b><span class="Apple-converted-space"> </span>num;</span></font><span style="font-size: 13px; font-family: Consolas, Courier, monospace !important;" class="">
</span></pre></div></div></div></blockquote></div></div></blockquote><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Here is food for your thoughts, you think WHERE is a keyword?! then look at this:</div><div class=""><br class=""></div><div class=""><div class=""><font color="#719ecf" face="Menlo" class="">var numbers = new int[]{0,1,23,4,5,6,7,87,9};</font></div><div class=""><font color="#719ecf" face="Menlo" class="">var numQuery = from num in numbers where (num % 2) == 0 select num;</font></div><div class=""><br class=""></div></div><div class=""><div class="">Program does not compile:</div><div class=""><br class=""></div></div><div class=""><font color="#ff2600" class=""><font face="Menlo" class="">// </font><font face="Menlo" class="">Error CS1935: An implementation of `Where' query expression pattern could not be found. Are you missing `System.Linq' using directive or `System.Core.dll' assembly reference? (CS1935) (SessionsFinder)</font></font></div><div class=""><font face="Menlo" color="#ff2600" class=""><br class=""></font></div><div class=""><div class=""><font face="Menlo" class=""><span style="color: rgb(113, 158, 207);" class="">using</span><span style="color: rgb(238, 238, 236);" class=""> </span></font><span style="font-family: Menlo; color: rgb(136, 138, 133);" class="">System</span><span style="font-family: Menlo; color: rgb(136, 138, 133);" class="">.</span><span style="font-family: Menlo; color: rgb(136, 138, 133);" class="">Linq</span><span style="font-family: Menlo; color: rgb(136, 138, 133);" class="">;</span></div><div class=""><div class=""><font color="#719ecf" face="Menlo" class="">var numbers = new int[]{0,1,23,4,5,6,7,87,9};</font></div><div class=""><font color="#719ecf" face="Menlo" class="">var numQuery = from num in numbers where (num % 2) == 0 select num;</font></div><div class=""><br class=""></div></div></div><div class=""><div class="">That program does compiles and runs fine. This tells you that “where" is not at all the ordinary keyword that it appears to be. hence my “it is not C# per-se, it is Linq”. </div></div></div></div></div></blockquote><div><br class=""></div><div>Digging into <a href="https://msdn.microsoft.com/en-us/library/bb397909.aspx" class="">https://msdn.microsoft.com/en-us/library/bb397909.aspx</a> and <a href="https://msdn.microsoft.com/en-us/library/the35c6y.aspx" class="">https://msdn.microsoft.com/en-us/library/the35c6y.aspx</a> tells me the following:</div><div>(1) `from`, `where` etc. are contextual keywords, but they are nonetheless keywords of C# and expressly *not* a specific feature of LINQ: "Although these new features are all used to a degree with LINQ queries, they are not limited to LINQ and can be used in any context where you find them useful."</div><div>(2) the compiler translates them into standard method calls (like Scala’s `for`-expression or Haskell’s `do`-notation). That is an integral part of C#.</div><div>(3) your error message originates from not having an implementation of a `Where`-method in scope. You could have provided one yourself instead of `using System.Linq`.</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class=""><div class="">And if you still wonder, then rewrite the code so that “WHERE” no longer looks like a keyword:</div><div class=""><br class=""></div><div class=""><font color="#0433ff" class="">var numQuery2 = numbers.Where( num => num %2 == 0);</font><span class="Apple-tab-span" style="color: rgb(4, 51, 255); white-space: pre;"> </span><font color="#4f7a28" class="">// exact same result as numQuery1</font></div></div></div></div></div></blockquote><div><br class=""></div>That’s exactly what I expected as it is the standard way syntactic language sugar is mapped to customizable behavior. Haskell’s `do`-notation or Scala’s `for`-expression are mapped likewise to functions on the types used.</div><div><br class=""></div><div>-Thorsten</div><div><br class=""></div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class=""><div class=""><br class=""></div><div class=""><br class=""></div><div class="">These are other real life examples from a OS X tool I wrote recently: </div><div class=""><br class=""></div><div class=""><font face="Menlo" class=""><span style="color:#3364a4;" class="">IEnumerable</span><span style="color:#222222;" class=""><</span><span style="color:#3364a4;" class="">Task</span><span style="color:#222222;" class=""><</span><span style="color:#3364a4;" class="">Session</span><span style="color:#222222;" class="">>></span><span style="color:#222222;" class=""> </span><span style="color:#222222;" class="">asyncOps</span><span style="color:#222222;" class=""> </span><span style="color:#222222;" class="">=</span><span style="color:#222222;" class=""> </span><span style="color:#009695;" class="">from</span><span style="color:#222222;" class=""> session </span><span style="color:#009695;" class="">in</span><span style="color:#222222;" class=""> </span><span style="color:#222222;" class="">sessions</span><span style="color:#222222;" class="">.</span><span style="color:#222222;" class="">Values</span><span style="color:#222222;" class=""> </span><span style="color:#009695;" class="">select</span><span style="color:#222222;" class=""> parseSessionDetails</span><span style="color:#222222;" class="">(</span><span style="color:#222222;" class="">updater</span><span style="color:#222222;" class="">,</span><span style="color:#222222;" class=""> </span><span style="color:#222222;" class="">parser</span><span style="color:#222222;" class="">,</span><span style="color:#222222;" class=""> </span><span style="color:#222222;" class="">session</span><span style="color:#222222;" class="">)</span><span style="color:#222222;" class="">;</span></font></div></div><div class=""><span style="font-family: Menlo; color: rgb(0, 150, 149);" class="">var</span><span style="font-family: Menlo; color: rgb(34, 34, 34);" class=""> </span><span style="font-family: Menlo; color: rgb(34, 34, 34);" class="">ul</span><span style="font-family: Menlo; color: rgb(34, 34, 34);" class=""> </span><span style="font-family: Menlo; color: rgb(34, 34, 34);" class="">=</span><span style="font-family: Menlo; color: rgb(34, 34, 34);" class=""> </span><span style="font-family: Menlo; color: rgb(34, 34, 34);" class="">node</span><span style="font-family: Menlo; color: rgb(34, 34, 34);" class="">.</span><span style="font-family: Menlo; color: rgb(34, 34, 34);" class="">Descendants</span><span style="font-family: Menlo; color: rgb(34, 34, 34);" class="">()</span><span style="font-family: Menlo; color: rgb(34, 34, 34);" class="">.</span><span style="font-family: Menlo; color: rgb(34, 34, 34);" class="">Where</span><span style="font-family: Menlo; color: rgb(34, 34, 34);" class="">(</span><span style="font-family: Menlo; color: rgb(34, 34, 34);" class="">x</span><span style="font-family: Menlo; color: rgb(34, 34, 34);" class=""> </span><span style="font-family: Menlo; color: rgb(34, 34, 34);" class="">=</span><span style="font-family: Menlo; color: rgb(34, 34, 34);" class="">></span><span style="font-family: Menlo; color: rgb(34, 34, 34);" class=""> </span><span style="font-family: Menlo; color: rgb(34, 34, 34);" class="">x</span><span style="font-family: Menlo; color: rgb(34, 34, 34);" class="">.</span><span style="font-family: Menlo; color: rgb(34, 34, 34);" class="">Name </span><span style="font-family: Menlo; color: rgb(34, 34, 34);" class="">==</span><span style="font-family: Menlo; color: rgb(34, 34, 34);" class=""> </span><span style="font-family: Menlo; color: rgb(219, 113, 0);" class="">"</span><span style="font-family: Menlo; color: rgb(219, 113, 0);" class="">ul</span><span style="font-family: Menlo; color: rgb(219, 113, 0);" class="">"</span><span style="font-family: Menlo; color: rgb(34, 34, 34);" class="">)</span><span style="font-family: Menlo; color: rgb(34, 34, 34);" class="">.</span><span style="font-family: Menlo; color: rgb(34, 34, 34);" class="">First</span><span style="font-family: Menlo; color: rgb(34, 34, 34);" class="">()</span><span style="font-family: Menlo; color: rgb(34, 34, 34);" class="">;</span></div><div class=""><br class=""></div><div class=""><br class=""></div></div></div></div></blockquote></div><br class=""></body></html>