<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Jun 10, 2016 at 1:09 PM, Vladimir.S <span dir="ltr"><<a href="mailto:svabox@gmail.com" target="_blank">svabox@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I don't think the 'where' in 'for' loop adds another dialect of Swift more than using of [Int] vs Array<Int> or shorthand syntax for Optionals adds it. (in addition to 'guard' vs 'if')<br></blockquote><div><br></div><div>As I mentioned above, `guard` and `if` each have uses that cannot be served by the other. Shorthand syntax for optional types serves, among other purposes, the aim of progressive disclosure of language features to learners (in the sense that a beginning user doesn't have to learn about enums before using optionals). [] syntax for arrays is long precedented from other languages in the C family and satisfies user expectations when they come from those languages. I acknowledge that meeting user expectations when they come from a related language, as well as learning and education, are valid aims. And I have put forward arguments that `where` does not serve any of these valid ends.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
So, it's just an opinion if 'where' in 'for' loop introduces new dialect or if it is a handy feature that can be used when it best suits the needs in some situation or even a metter of style(like [Int] vs Array<Int> or using .forEach vs for-in etc). </blockquote><div><br></div><div>But, `.forEach` cannot be used if you want to prematurely break from the loop, so again it cannot do what `for...in` can do. By contrast, `guard` can do everything `where` can do and more. Moreover, here we are talking about two aspects of the grammar, whereas `.forEach` is an stdlib method. As I've argued before, users expect to see functions they aren't familiar with--after all, any person can write a function and name it anything--but it elevates the learning curve to have keywords and syntaxes in the language itself which are redundant.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<br>
On 10.06.2016 20:17, Xiaodi Wu via swift-evolution wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
I think this idea--if you don't like it, then you don't have to use it--is<br>
indicative of a key worry here: it's inessential to the language and<br>
promotes dialects wherein certain people use it and others wherein they<br>
don't. This is an anti-goal.<br>
<br>
On Fri, Jun 10, 2016 at 12:10 let var go <<a href="mailto:letvargo@gmail.com" target="_blank">letvargo@gmail.com</a><br></span><div><div class="h5">
<mailto:<a href="mailto:letvargo@gmail.com" target="_blank">letvargo@gmail.com</a>>> wrote:<br>
<br>
Leave it in!<br>
<br>
It's a great little tool. I don't use it very often, but when I do it<br>
is because I've decided that in the context of that piece of code it<br>
does exactly what I want it to do with the maximum amount of clarity.<br>
<br>
If you don't like it, then don't use it, but I can't see how it<br>
detracts from the language at all.<br>
<br>
The *only* argument that I have heard for removing it is that some<br>
people don't immediately intuit how to use it. I didn't have any<br>
trouble with it at all. It follows one of the most basic programming<br>
patterns ever: "For all x in X, if predicate P is true, do something."<br>
The use of the keyword "where" makes perfect sense in that context, and<br>
when I read it out loud, it sounds natural: "For all x in X where P, do<br>
something." That is an elegant, succinct, and clear way of stating<br>
exactly what I want my program to do.<br>
<br>
I don't doubt that it has caused some confusion for some people, but<br>
I'm not sold that that is a good enough reason to get rid of it. It<br>
seems strange to get rid of a tool because not everyone understands how<br>
to use it immediately, without ever having to ask a single question. As<br>
long as its not a dangerous tool (and it isn't), then keep it in the<br>
workshop for those times when it comes in handy. And even if there is<br>
some initial confusion, it doesn't sound like it lasted that long. It's<br>
more like, "Does this work like X, or does this work like Y? Let's<br>
see...oh, it works like X. Ok." That's the entire learning<br>
curve...about 5 seconds of curiosity followed by the blissful feeling<br>
of resolution.<br>
<br>
On Fri, Jun 10, 2016 at 9:32 AM Xiaodi Wu via swift-evolution<br></div></div><span class="">
<<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a> <mailto:<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>>> wrote:<br>
<br>
On Fri, Jun 10, 2016 at 11:23 AM, Sean Heber via swift-evolution<br></span><div><div class="h5">
<<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a> <mailto:<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>>> wrote:<br>
<br>
> 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>
Weird. My own Swift projects (not on Github :P) use “where” all<br>
the time with for loops. I really like it and think it reads<br>
*and* writes far better as well as makes for nicer one-liners.<br>
In one project, by rough count, I have about 20 that use<br>
“where” vs. 40 in that same project not using “where”.<br>
<br>
In another smaller test project, there are only 10 for loops,<br>
but even so one still managed to use where.<br>
<br>
Not a lot of data without looking at even more projects, I<br>
admit, but this seems to suggest that the usage of “where” is<br>
going to be very developer-dependent. Perhaps there’s some<br>
factor of prior background at work here? (I’ve done a lot of<br>
SQL in another life, for example.)<br>
<br>
<br>
That is worrying if true, because it suggests that it's enabling<br>
'dialects' of Swift, an explicit anti-goal of the language.<br>
<br>
<br>
<br>
I feel like “where” is a more declarative construct and that we<br>
should be encouraging that way of thinking in general. When<br>
using it, it feels like “magic” for some reason - even though<br>
there’s nothing special about it. It feels like I’ve made the<br>
language work *for me* a little bit rather than me having to<br>
contort my solution to the will of the language. This may be<br>
highly subjective.<br>
<br>
l8r<br>
Sean<br>
<br>
_______________________________________________<br>
swift-evolution mailing list<br></div></div>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a> <mailto:<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>><span class=""><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>
<br>
_______________________________________________<br>
swift-evolution mailing list<br></span>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a> <mailto:<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>><span class=""><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>
<br>
<br>
<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>
<br>
</span></blockquote>
</blockquote></div><br></div></div>