[swift-evolution] [Pitch] Retiring `where` from for-in loops

Fri Jun 10 14:14:20 CDT 2016

It would not be like going back to Windows 95... and I did not mention the
infamous OSR3 release to make that harsh of a point :P...

On Fri, Jun 10, 2016 at 8:09 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:

> On Fri, Jun 10, 2016 at 2:06 PM, Goffredo Marocchi <panajev at gmail.com>
> wrote:
>
>> 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.
>>
>> 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.
>>
>
> 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?
>
>
>
>>
>> On Fri, Jun 10, 2016 at 7:59 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>>
>>> On Fri, Jun 10, 2016 at 1:11 PM, Goffredo Marocchi <panajev at gmail.com>
>>> wrote:
>>>
>>>> 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.
>>>>
>>>
>>> Architects are constrained to craft buildings that will stand in the
>>> face of gravity, and even painters don't have pigments for every color
>>> visible to the human eye. There's a wonderful novel, _Gadsby_, written
>>> without the letter 'e'; I haven't read it but I understand it's truly an
>>> accomplishment. This is not so drastic here. In this case, the apt analogy
>>> would be that we find the letter 'a with circle on top' to be posing some
>>> pesky problems; do you think you could write a novel in English without
>>> using 'a with circle on top'? I wager that your creativity will not suffer
>>> (unless your novel describes a trip to IKEA, in which case I'm sorry).
>>>
>>>
>>>>
>>>> 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...
>>>>
>>>> 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 "it depends... What's the context? What is the problem I need to
>>>> solve, what are the constraints and the data set I am working on?").
>>>>
>>>> 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.
>>>>
>>>> Sent from my iPhone
>>>>
>>>> On 10 Jun 2016, at 18:30, let var go via swift-evolution <
>>>> swift-evolution at swift.org> wrote:
>>>>
>>>> I respect that anti-goal, but I think being over-rigid about limiting
>>>> developers' choice of expression is also an anti-goal.
>>>>
>>>> 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 "style", 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 "dialects."
>>>>
>>>> But most importantly (and this is really the kicker for me) there are
>>>> times when the "where" syntax provides the maximum amount of clarity in the
>>>> context of my code, and I don't want to lose that expressive power.
>>>>
>>>> On Fri, Jun 10, 2016 at 10:17 AM Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>>>>
>>>>> 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.
>>>>>
>>>>> On Fri, Jun 10, 2016 at 12:10 let var go <letvargo at gmail.com> wrote:
>>>>>
>>>>>> Leave it in!
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>> If you don't like it, then don't use it, but I can't see how it
>>>>>> detracts from the language at all.
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>> On Fri, Jun 10, 2016 at 9:32 AM Xiaodi Wu via swift-evolution <
>>>>>> swift-evolution at swift.org> wrote:
>>>>>>
>>>>>>> On Fri, Jun 10, 2016 at 11:23 AM, Sean Heber via swift-evolution <
>>>>>>> swift-evolution at swift.org> wrote:
>>>>>>>
>>>>>>>> > 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.
>>>>>>>>
>>>>>>>> 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”.
>>>>>>>>
>>>>>>>> In another smaller test project, there are only 10 for loops, but
>>>>>>>> even so one still managed to use where.
>>>>>>>>
>>>>>>>> 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.)
>>>>>>>>
>>>>>>>
>>>>>>> That is worrying if true, because it suggests that it's enabling
>>>>>>> 'dialects' of Swift, an explicit anti-goal of the language.
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> 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.
>>>>>>>>
>>>>>>>> l8r
>>>>>>>> Sean
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> swift-evolution mailing list
>>>>>>>> swift-evolution at swift.org
>>>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> swift-evolution mailing list
>>>>>>> swift-evolution at swift.org
>>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>>>>
>>>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution at swift.org
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160610/e96b6cf8/attachment.html>