On Mon, Jun 13, 2016 at 9:27 AM, Vladimir.S <sva...@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 <bkn...@me.com >> <mailto:bkn...@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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org> >>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>> >>>> >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> >> >> >> >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution >> >>
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution