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

Xiaodi Wu xiaodi.wu at gmail.com
Mon Jun 13 09:44:34 CDT 2016 

On Mon, Jun 13, 2016 at 9:27 AM, Vladimir.S <svabox at gmail.com> wrote:

> IMO `for-in` is a special kind of loop to manipulate(iterate) a
> collection, and was introduced because we so *often* needs to iterate
> collections that we need a *sugar* for this (you can do all the same with
> `while` loop).
>

Sequences, not just collections.

It's rather tricky to write a `while` loop *correctly* to do the same thing
as a `for` loop, and it exposes the concept of the underlying iterator,
which is a more advanced concept. This is why the `for...in` loop hold its
own weight as sugar. By contrast, `while` does not, because it is trivial
to write an `if` or `guard` statement correctly, and mastering the concept
of a conditional statement is a prerequisite for mastering loops. For these
reasons, it's not apt to compare `while` clauses with `for...in` loops.


> *Filtering* is another important operation we often need during the
> iteration of collection.


I think the evidence has shown that it's actually not very often that you
need to do so.


> This is why many of us want to keep `where` for `for-in` loop. Yes, as
> sugar, because it really simplifies our every day coding(processing of
> collections) and makes the code more readable(IMO) and understandable(IMO).
>

FWIW, IMO, it's less readable and less understandable. But there's no point
in going back and forth on this.


> Personally I don't insist on `where` keyword, probably we can find another
> word, so it will not be mixed with `where` in other places of the language.
>
> Why not `filter` instead of `where` ?
>
> for item in collection filter item < 10 {..}
>
> we have .filter for collections, it is clear what it means, `filter` in
> `for-in` mimics the same behavior, etc
>
> I'd even suggest to make `for-in` loop more powerful with adding suggested
> 'while' but as under another name. So, `for-in` will be a powerful
> construct to iterate, filter and break processing of collections - the only
> one purpose why we need `for-in` at all.
>

We already have keywords for breaking and for prematurely terminating from
a loop. They're called `break` and `continue`, and they work inside every
loop.


>
> for item in collection until item > 100 {..}
> or
> for item in collection break item > 100 {..}
> or
> for item in collection breakif item > 100 {..}
> or
> for item in collection limit item > 100 {..}
> or
> for item in collection stop item > 100 {..}
> or other keyword.
>
>
> On 13.06.2016 16:36, Xiaodi Wu via swift-evolution wrote:
>
>> On Mon, Jun 13, 2016 at 8:16 AM, Brandon Knope <bknope at me.com
>> <mailto:bknope at me.com>> wrote:
>>
>>     Are you really surprised that some people don't want this taken away?
>>
>>
>> Nope, that's to be expected.
>>
>>
>>     The burden should be on those that want it taken out of the language
>>     and not those that want it kept. After all something is being removed
>>     and it should be a delicate process.
>>
>>
>> Agreed. We who think it's better to take this syntax out have advanced an
>> argument with several prongs. Namely, that the `where` clause serves no
>> independent purpose; that a more general solution has already been added
>> to
>> the language (as well as another in the stdlib); that the `where` clause
>> is
>> not necessary for progressive disclosure to new users before they're ready
>> for the general solution; that it is, at present, rarely used in practice;
>> that it has no analog in other commonly used general purpose languages in
>> the C family; that it is the remnant of a direction in which the core team
>> later decided not to pursue; and that, given its lack of utility, lack of
>> use, and vestigial state, being the cause of confusion even among a small
>> number of users (if their number be small) is grounds to conclude that it
>> is harmful to the language and therefore ought to be removed.
>>
>>
>>     Don't be surprised when the defenders say it is more readable to them.
>>     That is a *sound* argument in my opinion.
>>
>>
>> IMO, it cannot stand on its own as a complete argument for saving a
>> feature
>> in the face of the arguments we've advanced. Couldn't you say the same for
>> `++` or `for;;` loops? I'd say our case is at least as strong as that for
>> `for;;` loops. By comparison, if I recall, the `for;;` loop was argued to
>> be ill-fitting the rest of the language and lacking in usage, but it
>> certainly had utility independent of `for...in` loops and was well
>> precedented in C languages.
>>
>>
>>
>>     Brandon
>>
>>     Sent from my iPad
>>
>>     On Jun 13, 2016, at 8:33 AM, Xiaodi Wu via swift-evolution
>>     <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>
>>     This is not a sound argument. If your filtering can be expressed as a
>>>     where clause, then you would only have to read one line into the loop
>>>     to see it in the form of a guard clause.
>>>
>>>     Moreover, if what you're arguing is that you shouldn't ever have to
>>>     *read* inside the loop to know if a sequence is filtered, how do you
>>>     propose that we do that? Remove the continue keyword?
>>>
>>>     On Mon, Jun 13, 2016 at 6:16 AM Jean-Daniel Dupas via swift-evolution
>>>     <swift-evolution at swift.org <mailto:swift-evolution at swift.org>>
>>> wrote:
>>>
>>>         -1 for the removal.
>>>
>>>         When I read code, I find it far more visible that a loop is over
>>>         a filter list when the filter clause is on the same line, than
>>>         when the filter clause is inside the loop.
>>>
>>>         Having to read the full content of the loop to determine if the
>>>         list is filtered or not is not an improvement IMHO.
>>>
>>>         Moreover, I find it far cleaner to use the where clause that
>>>         having to remember than I have to use the lazy accessor to avoid
>>>         a performance hit.
>>>
>>>         Le 13 juin 2016 à 06:39, Charlie Monroe via swift-evolution
>>>>         <swift-evolution at swift.org <mailto:swift-evolution at swift.org>>
>>>> a
>>>>         écrit :
>>>>
>>>>         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.
>>>>>
>>>>>         -- E
>>>>>
>>>>
>>>>         Not to undermine this fact, but I believe the fact that `where`
>>>>         can be used in a for loop is not widely known. I didn't know
>>>>         about it until about a month ago (haven't really read much docs,
>>>>         but most people don't either).
>>>>
>>>>         But after I found out about it, I started using it and it IMHO
>>>>         improved readability of my code. Not by much, but it's the
>>>>         little things that make you smile, right?
>>>>
>>>>         Many people here argument that `where` is a Swift speciality and
>>>>         needs to be learned by the developer - the alternative is to
>>>>         teach the person what's the proper alternative - that using
>>>>         .filter can have performance impact and that the *correct* way
>>>>         is to use guard within the for loop. And that's IMHO much worse
>>>>         than teaching a person about using `where` within a for loop.
>>>>
>>>>         _______________________________________________
>>>>>         swift-evolution mailing list
>>>>>         swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>>>>         https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>>
>>>>
>>>>         _______________________________________________
>>>>         swift-evolution mailing list
>>>>         swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>>>         https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>
>>>
>>>         _______________________________________________
>>>         swift-evolution mailing list
>>>         swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>>         https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>>     _______________________________________________
>>>     swift-evolution mailing list
>>>     swift-evolution at swift.org <mailto: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/20160613/169632ee/attachment.html>

More information about the swift-evolution mailing list