<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Jun 10, 2016 at 1:20 PM, Goffredo Marocchi <span dir="ltr"><<a href="mailto:panajev@gmail.com" target="_blank">panajev@gmail.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>If the litmus test is whether using something can go awry and can go awry at runtime then you are going to have to chop off a lot of parts of most languages. Also, some programmers do not mind not being protected from themselves and trade that for extra freedom... which is not a bad thing in and of itself</div></div></blockquote><div><br></div><div>Again, I agree. What I'm arguing here is that it can go awry *and* doesn't offer extra freedom as a trade-off (*nor* serves a pedagogical purpose, *nor* is necessary to support a key and unique feature of Swift). I don't buy the argument that the freedom worth gaining is the trivial freedom from using `guard`. That's like saying: I don't like arrays, and I'd like something to give me the "freedom" from using them.</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> In the end the question is an old one indeed, where do you draw the line between safety and freedom... as corny as it sounds. There are people on both sides.</div></div></blockquote><div><br></div><div>As I outlined above, I reject that there is any tradeoff here between safety and freedom. I see no freedom gained, only safety lost. Therefore, there doesn't need to be a defined line to come to a conclusion. It's not even on the same playing field.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div>I do not want a swift compiler flag that takes my idea and gets a team of contractors to build it... to take it to a ridiculous extreme :).</div><div><br><div>Sent from my iPhone</div></div><div><div class="h5"><div><br>On 10 Jun 2016, at 19:10, Xiaodi Wu 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 dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Jun 10, 2016 at 12:47 PM, James Berry <span dir="ltr"><<a href="mailto:jberry@rogueorbit.com" target="_blank">jberry@rogueorbit.com</a>></span> wrote:<br><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><blockquote type="cite"><div>On Jun 10, 2016, at 10:17 AM, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br><div><div style="white-space:pre-wrap">I think this idea--if you don't like it, then you don't have to use it--is indicative of a key worry here: it's inessential to the language and promotes dialects wherein certain people use it and others wherein they don't. This is an anti-goal.<br></div></div></blockquote><div><br></div></span><div>I’m not sold on the argument that there can’t be areas of the language that are inessential. Yes, we could build a language with extremely limited control structures (conditional branch and goto), and they would be used by 100% of the users. Beyond that, however, everything is “inessential”. Adding room for elegance and expressiveness, even when perhaps initially seldom used, doesn’t seem wrong: this language is still young, after all. Let’s not shoot decide a feature isn’t used before we even give it a chance to be recognized as a feature.</div></div></div></blockquote><div><br></div><div>I do agree with the premise here. There is absolutely something to be said for elegance and expressiveness. Moreover, expressiveness goes hand in hand with facilitating correctness. We could reduce everything to goto's and conditional branches, but correctness suffers greatly and readability of the code would be abysmal--and I think I'll find agreement that it's a solidly grounded opinion.</div><div><br></div><div>So "inessential" alone is not a good sole criterion--I agree. But it is one of several prongs here: `where` is not only inessential, I argue that it lacks expressiveness (in that what is enabled by it can be expressed equally or even more cogently with `guard`, a more general and more expressive syntax overall), and it detracts from rather than helps with writing correct code, because we hear attestations that its use has gone awry (and the going awry happens at runtime!). So in essence, I would be content with inessential but expressive solutions, but here I argue that `where` is neither essential nor expressive.</div><div><br></div><div>Elegance is in the eye of the beholder, but FWIW I do not find `where` elegant; it irks me greatly from an aesthetic point of view just as it delights others. I see no point in debating personal taste, however.</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><br></div><div>I would argue that at least one reason the where clause is little used on for-in loops in code in the field is that it’s barely documented. I don’t see any reference to it, or example of it, in the Swift 2.2 language guide. One has to read the grammar for the for statement in the more technical Language Reference in order to find it, and even there it’s behavior is not defined that I can see.</div><div><br></div><div>Using or not using a feature does not create a dialect of a language.</div><div><div><div><br></div><br><blockquote type="cite"><div><br><div class="gmail_quote"><div dir="ltr">On Fri, Jun 10, 2016 at 12:10 let var go <<a href="mailto:letvargo@gmail.com" target="_blank">letvargo@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Leave it in!<div><br><div>It's a great little tool. I don't use it very often, but when I do it is because I've decided that in the context of that piece of code it does exactly what I want it to do with the maximum amount of clarity.</div><div><br></div></div><div>If you don't like it, then don't use it, but I can't see how it detracts from the language at all.</div><div><br></div><div>The *only* argument that I have heard for removing it is that some people don't immediately intuit how to use it. I didn't have any trouble with it at all. It follows one of the most basic programming patterns ever: "For all x in X, if predicate P is true, do something." The use of the keyword "where" makes perfect sense in that context, and when I read it out loud, it sounds natural: "For all x in X where P, do something." That is an elegant, succinct, and clear way of stating exactly what I want my program to do.</div><div><br></div><div>I don't doubt that it has caused some confusion for some people, but I'm not sold that that is a good enough reason to get rid of it. It seems strange to get rid of a tool because not everyone understands how to use it immediately, without ever having to ask a single question. As long as its not a dangerous tool (and it isn't), then keep it in the workshop for those times when it comes in handy. And even if there is some initial confusion, it doesn't sound like it lasted that long. It's more like, "Does this work like X, or does this work like Y? Let's see...oh, it works like X. Ok." That's the entire learning curve...about 5 seconds of curiosity followed by the blissful feeling of resolution.</div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Jun 10, 2016 at 9:32 AM Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Jun 10, 2016 at 11:23 AM, Sean Heber via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>> And to follow-up to myself once again, I went to my "Cool 3rd Party Swift Repos" folder and did the same search. Among the 15 repos in that folder, a joint search returned about 650 hits on for-in (again with some false positives) and not a single for-in-while use.<br>
<br>
</span>Weird. My own Swift projects (not on Github :P) use “where” all the time with for loops. I really like it and think it reads *and* writes far better as well as makes for nicer one-liners. In one project, by rough count, I have about 20 that use “where” vs. 40 in that same project not using “where”.<br>
<br>
In another smaller test project, there are only 10 for loops, but even so one still managed to use where.<br>
<br>
Not a lot of data without looking at even more projects, I admit, but this seems to suggest that the usage of “where” is going to be very developer-dependent. Perhaps there’s some factor of prior background at work here? (I’ve done a lot of SQL in another life, for example.)<br></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>That is worrying if true, because it suggests that it's enabling 'dialects' of Swift, an explicit anti-goal of the language.</div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I feel like “where” is a more declarative construct and that we should be encouraging that way of thinking in general. When using it, it feels like “magic” for some reason - even though there’s nothing special about it. It feels like I’ve made the language work *for me* a little bit rather than me having to contort my solution to the will of the language. This may be highly subjective.<br>
<br>
l8r<br>
<span><font color="#888888">Sean<br>
</font></span><div><div><br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</div></div></blockquote></div></div></div>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div>
</blockquote></div>
_______________________________________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></div></blockquote></div></div></div><br></div></blockquote></div><br></div></div>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></div></div></div></blockquote></div><br></div></div>