<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Jun 10, 2016 at 2:06 PM, Goffredo Marocchi <span dir="ltr">&lt;<a href="mailto:panajev@gmail.com" target="_blank">panajev@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>I was not advocating the lack of constraints, programmers like all other artists (and engineers, which are artists too ;)), but that the beauty is the moderation of the two extremes :). ... and that architects leave the problems you are talking about to the structural engineer :P.<br><br></div>Gravity is a constrain, but a different one than having to use only a certain pencil to do your sketches with and only being able to use Windows 95 OSR 3 to work on or even weirder limitations.<br></div></blockquote><div><br></div><div>The question is, does removing `where` feel to you like going from OS X 10.11 to Windows 95, or is it more like going from OS X 10.11.4 to OS X 10.11.3?</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 10, 2016 at 7:59 PM, Xiaodi Wu <span dir="ltr">&lt;<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>&gt;</span> wrote:<br><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"><span>On Fri, Jun 10, 2016 at 1:11 PM, Goffredo Marocchi <span dir="ltr">&lt;<a href="mailto:panajev@gmail.com" target="_blank">panajev@gmail.com</a>&gt;</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>I think sometimes the community in this mailing list loses sight on the fact that coding is a creative  endeavour much similar to architectural design or painting. There may be math and well researched and structured ideas in place, but it requires creativity too.</div></div></blockquote><div><br></div></span><div>Architects are constrained to craft buildings that will stand in the face of gravity, and even painters don&#39;t have pigments for every color visible to the human eye. There&#39;s a wonderful novel, _Gadsby_, written without the letter &#39;e&#39;; I haven&#39;t read it but I understand it&#39;s truly an accomplishment. This is not so drastic here. In this case, the apt analogy would be that we find the letter &#39;a with circle on top&#39; to be posing some pesky problems; do you think you could write a novel in English without using &#39;a with circle on top&#39;? I wager that your creativity will not suffer (unless your novel describes a trip to IKEA, in which case I&#39;m sorry).</div><div><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><br></div><div>Trying to force a strict one size fits all The One True standard usually ends up fragmenting the standard further, by adding yet another take on what is the most orthodox implementation and who are the heretics...</div><div><br></div><div>I do not think dismissing the idea of having more than one way of skinning the proverbial cat as an anti-goal is doing a good service to the community or the language as it completely disregards context, people differing idea of the subjective best coding style and patterns (which pattern do I use? Which algorithm do I use to sort this data set with? A good engineer will give you a direct and concise answer, but a better one will say &quot;it depends... What&#39;s the context? What is the problem I need to solve, what are the constraints and the data set I am working on?&quot;).</div><div><br></div><div>The way some users seem to want Swift to follow sounds like protecting users from mistakes by sometimes removing the ability which could lead to mistakes in the first place, but that removes all the good things you could do if you were to trust developers with the extra responsibility.</div><div><br>Sent from my iPhone</div><div><div><div><br>On 10 Jun 2016, at 18:30, let var go via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr"><div>I respect that anti-goal, but I think being over-rigid about limiting developers&#39; choice of expression is also an anti-goal.</div><div><br></div><div>To me, it is like guard statements vs. if-let statements. Some people find one to be more clear than the other. Often times the best choice depends on the context. Sometimes a guard statement can be re-written as an if-let statement in a way that makes the code more clear, and vice versa. And different people will inevitably have different personal preferences - their own &quot;style&quot;, if you will - and will favor one over the other. But it would be a mistake to force everyone into one box in order to prevent the fracturing of the Swift community into &quot;dialects.&quot;</div><div><br></div><div>But most importantly (and this is really the kicker for me) there are times when the &quot;where&quot; syntax provides the maximum amount of clarity in the context of my code, and I don&#39;t want to lose that expressive power.<br></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Jun 10, 2016 at 10:17 AM Xiaodi Wu &lt;<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="white-space:pre-wrap">I think this idea--if you don&#39;t like it, then you don&#39;t have to use it--is indicative of a key worry here: it&#39;s inessential to the language and promotes dialects wherein certain people use it and others wherein they don&#39;t. This is an anti-goal.<br></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Jun 10, 2016 at 12:10 let var go &lt;<a href="mailto:letvargo@gmail.com" target="_blank">letvargo@gmail.com</a>&gt; 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&#39;s a great little tool. I don&#39;t use it very often, but when I do it is because I&#39;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&#39;t like it, then don&#39;t use it, but I can&#39;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&#39;t immediately intuit how to use it. I didn&#39;t have any trouble with it at all. It follows one of the most basic programming patterns ever: &quot;For all x in X, if predicate P is true, do something.&quot; The use of the keyword &quot;where&quot; makes perfect sense in that context, and when I read it out loud, it sounds natural: &quot;For all x in X where P, do something.&quot; 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&#39;t doubt that it has caused some confusion for some people, but I&#39;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&#39;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&#39;t sound like it lasted that long. It&#39;s more like, &quot;Does this work like X, or does this work like Y? Let&#39;s see...oh, it works like X. Ok.&quot; That&#39;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 &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; 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">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>&gt; And to follow-up to myself once again, I went to my &quot;Cool 3rd Party Swift Repos&quot; 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&#39;s enabling &#39;dialects&#39; 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>
</blockquote></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></div></div><br></div></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div></div>