[swift-evolution] [Pitch] Retiring `where` from for-in loops
Vladimir.S
svabox at gmail.com
Mon Jun 13 09:27:11 CDT 2016
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).
*Filtering* is another important operation we often need during the
iteration of collection. 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).
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.
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
>
More information about the swift-evolution
mailing list