filter() is and prefix(while:) will be available on all sequences. The for...in loop only traverses through sequences.
The meaning of the proposed while is not at all a pair for where, since where clauses in while loops would do the same thing as while clauses in for loops. That's crazy. On Tue, Jun 7, 2016 at 06:20 Vladimir.S via swift-evolution < [email protected]> wrote: > My +1 to the proposal and for Charlie's opinion. I believe `while` in `for` > loop would be very handy and helpful in some situations, it is a pair for > existed `where`, its meaning is obvious, and its existence can't depend on > existence of any method in collections. I'd like to see a formal proposal > for this feature. > > On 07.06.2016 8:18, Charlie Monroe via swift-evolution wrote: > > I strongly disagree. > > > > Exchanging > > > > for result in results where result.value != .Warning while result.value > != > > .Error { > > /// ... > > } > > > > for either > > > > for result in results.filter({ $0.value != .Warning }).prefix(while: { > > $0.value != .Error })) { > > /// ... > > } > > > > or > > > > for result in results { > > if result.value == .Warning { continue } > > if result.value == .Error { break } > > > > /// ... > > } > > > > Seems like an absolute step back. Not to mention filter(_:) doesn't > return > > a lazy collection, but will recreate it, while the `where` will do > > on-the-fly check. > > > >> On Jun 7, 2016, at 1:34 AM, Xiaodi Wu via swift-evolution > >> <[email protected] <mailto:[email protected]>> wrote: > >> > >> Personally, given this discussion and the one about `where` in if and > >> while statements, I would not be opposed to elimination of `where` in > >> control statements altogether. > >> > >> My reasoning would be that words like filter and prefix unambiguously > >> indicate what happens to elements of a sequence for which the predicate > >> returns false, whereas words like where and while are ambiguous. > >> > >> On Mon, Jun 6, 2016 at 17:52 Tim Vermeulen <[email protected] > >> <mailto:[email protected]>> wrote: > >> > >> I didn’t mean we should really get rid of the `where` clause, it’s > >> great. I guess the point I was trying to make is that we can use a > >> `where` clause with a `for` loop in Swift, despite the existence of > >> the `filter` method. So despite `prefix(while:)` in Swift 3, there > >> might be room for a `while` clause. I think it makes the code a lot > >> more readable, much like how `where` can make a `for` loop a lot > more > >> readable than using `filter`. > >> > >> > The burden of proof for adding new features is different from that > >> for taking away existing features. > >> > > >> > If a feature doesn't yet exist, a successful proposal will show > how > >> it provides additional and non-trivial utility. If a feature already > >> exists, a successful proposal to remove it will show how it is > >> harmful to the language or contrary to the direction in which it is > >> evolving. > >> > > >> > On Mon, Jun 6, 2016 at 15:38 Tim Vermeulen<[email protected] > >> <mailto:[email protected]>(mailto:[email protected] > >> <mailto:[email protected]>)>wrote: > >> > > The functionality of the `where` clause in `for` loops also > >> already can be mimicked using `filter`. Wouldn’t we have to get ride > >> of the `where` clause by that logic? > >> > > > >> > > >The functionality being asked for here is already accepted for > >> inclusion to Swift as a method on Sequence named `prefix(while:)` > >> (SE-0045): > >> > > > > >> > > >`for element in array.prefix(while: { someCondition($0) }) { > ... }` > >> > > >On Mon, Jun 6, 2016 at 14:31 T.J. Usiyan via > >> swift-evolution<[email protected] > >> <mailto:[email protected]>(mailto:[email protected] > >> <mailto:[email protected]>)(mailto: > [email protected] > >> <mailto:[email protected]>)>wrote: > >> > > >>(As I said, I can live with `while`. I am simply presenting a > >> potential point of confusion.) > >> > > >>You aren't evaluating the statements in the loop 'while' the > >> condition isn't met. The first time that the condition isn't met, > >> evaluation of the loop stops. I get that this is technically true > for > >> the `while` construct but I suggest that the only reason that it > >> works there is that 'stopping the first time that the condition > isn't > >> met' *is* the construct. Here, we have a loop that we execute for > >> each thing and we're tacking on/intermingling the `while` construct. > >> > > >> > >> > > >> > >> > > >> > >> > > >>On Mon, Jun 6, 2016 at 2:19 PM, Thorsten > >> Seitz<[email protected] > >> <mailto:[email protected]>(mailto:[email protected] > >> <mailto:[email protected]>)(mailto:[email protected] > >> <mailto:[email protected]>)>wrote: > >> > > >>> > >> > > >>>>Am 06.06.2016 um 19:43 schrieb Tim Vermeulen via > >> swift-evolution<[email protected] > >> <mailto:[email protected]>(mailto:[email protected] > >> <mailto:[email protected]>)(mailto: > [email protected] > >> <mailto:[email protected]>)>: > >> > > >>>> > >> > > >>>>I also considered `until`, but it would be a bit confusing > >> that `where` makes sure a condition is met, while `until` makes sure > >> the condition isn’t met. I think `while` makes more sense because it > >> corresponds to `break` in the same way that `where` corresponds to > >> `continue`. > >> > > >>> > >> > > >>>That's a good argument! The only drawback is that `while` and > >> `where` look quite similar at a glance. > >> > > >>> > >> > > >>>-Thorsten > >> > > >>> > >> > > >>>> > >> > > >>>>>`while`, to me, actually reads like it should do what > >> `where` does. > >> > > >>>> > >> > > >>>>To me, `while` reads like it should stop the loop once the > >> condition isn’t met, just like in a while loop. > >> > > >>>> > >> > > >>>>>I hadn't thought about `while` in this regard but wouldn't > >> `until` make more sense? `while`, to me, actually reads like it > >> should do what `where` does. In any case, whether it is `while` or > >> `where`, this seems like a reasonable feature in my opinion. > >> > > >>>>> > >> > > >>>>>TJ > >> > > >>>>> > >> > > >>>>>On Mon, Jun 6, 2016 at 5:15 AM, Tim Vermeulen via > >> swift-evolution<[email protected] > >> <mailto:[email protected]>(mailto:[email protected] > >> <mailto:[email protected]>)(mailto: > [email protected] > >> <mailto:[email protected]>)(mailto: > [email protected] > >> <mailto:[email protected]>)>wrote: > >> > > >>>>>>We can already use a where clause in a for loop like this: > >> > > >>>>>> > >> > > >>>>>>for element in array where someCondition(element) { > >> > > >>>>>>// … > >> > > >>>>>>} > >> > > >>>>>> > >> > > >>>>>>which basically acts like > >> > > >>>>>> > >> > > >>>>>>for element in array { > >> > > >>>>>>guard someCondition(element) else { continue } > >> > > >>>>>>// … > >> > > >>>>>>} > >> > > >>>>>> > >> > > >>>>>>Sometimes you want to break out of the loop when the > >> condition isn’t met instead. I propose a while clause: > >> > > >>>>>> > >> > > >>>>>>for element in array while someCondition(element) { > >> > > >>>>>>// … > >> > > >>>>>>} > >> > > >>>>>> > >> > > >>>>>>which would be syntactic sugar for > >> > > >>>>>> > >> > > >>>>>>for element in array { > >> > > >>>>>>guard someCondition(element) else { break } > >> > > >>>>>>… > >> > > >>>>>>} > >> > > >>>>>> > >> > > >>>>>>I can see this particularly being useful if we have a > >> sorted array and we already know that once the condition isn’t met, > >> it won’t be met either for subsequent elements. Another use case > >> could be an infinite sequence that we want to cut off somewhere > >> (which is simply not possible using a where clause). > >> > > >>>>>>_______________________________________________ > >> > > >>>>>>swift-evolution mailing list > >> > > >>>>>>[email protected] > >> <mailto:[email protected]>(mailto:[email protected] > >> <mailto:[email protected]>)(mailto: > [email protected] > >> <mailto:[email protected]>)(mailto: > [email protected] > >> <mailto:[email protected]>) > >> > > >>>>>>https://lists.swift.org/mailman/listinfo/swift-evolution > >> > > >>>>_______________________________________________ > >> > > >>>>swift-evolution mailing list > >> > > >>>>[email protected] > >> <mailto:[email protected]>(mailto:[email protected] > >> <mailto:[email protected]>)(mailto: > [email protected] > >> <mailto:[email protected]>) > >> > > >>>>https://lists.swift.org/mailman/listinfo/swift-evolution > >> > > >> > >> > > >>_______________________________________________ > >> > > >>swift-evolution mailing list > >> > > >>[email protected] > >> <mailto:[email protected]>(mailto:[email protected] > >> <mailto:[email protected]>)(mailto: > [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 >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
