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 <[email protected]
<mailto:[email protected]>> 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
<[email protected] <mailto:[email protected]>> 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
<[email protected] <mailto:[email protected]>> 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
<[email protected] <mailto:[email protected]>> 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
[email protected] <mailto:[email protected]>
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected] <mailto:[email protected]>
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected] <mailto:[email protected]>
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected] <mailto:[email protected]>
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
