On Tue, Jun 7, 2016 at 2:16 PM, Tim Vermeulen <tvermeu...@me.com> wrote:
> > 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. > > It sounds crazy, but it’s the nature of the while loop. A where clause in > a while loop also has a different result than a where clause in a for loop. > I know. And SE-0099 proposed to eliminate it, and I am very supportive of that. For all of the reasons outlined in that conversation (including the different behaviors in while and for loops), I arrive at the conclusion that `where` is unsuitable for use in all condition statements and would support its complete elimination from the language. > > > 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< > swift-evolution@swift.org(mailto:swift-evolution@swift.org)>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 > > > >><swift-evolution@swift.org(mailto:swift-evolution@swift.org)<mailto: > swift-evolution@swift.org>>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<tvermeu...@me.com(mailto: > tvermeu...@me.com) > > > >><mailto:tvermeu...@me.com>>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<tvermeu...@me.com > (mailto:tvermeu...@me.com) > > > >><mailto:tvermeu...@me.com>(mailto:tvermeu...@me.com > > > >><mailto:tvermeu...@me.com>)>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<swift-evolution@swift.org(mailto: > swift-evolution@swift.org) > > > >><mailto:swift-evolution@swift.org>(mailto:swift-evolution@swift.org > > > >><mailto:swift-evolution@swift.org>)(mailto:swift-evolution@swift.org > > > >><mailto:swift-evolution@swift.org>)>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<tseit...@icloud.com(mailto:tseit...@icloud.com) > > > >><mailto:tseit...@icloud.com>(mailto:tseit...@icloud.com > > > >><mailto:tseit...@icloud.com>)(mailto:tseit...@icloud.com > > > >><mailto:tseit...@icloud.com>)>wrote: > > > >>>>>>> > > > >>>>>>>>Am 06.06.2016 um 19:43 schrieb Tim Vermeulen via > > > >>swift-evolution<swift-evolution@swift.org(mailto: > swift-evolution@swift.org) > > > >><mailto:swift-evolution@swift.org>(mailto:swift-evolution@swift.org > > > >><mailto:swift-evolution@swift.org>)(mailto:swift-evolution@swift.org > > > >><mailto:swift-evolution@swift.org>)>: > > > >>>>>>>> > > > >>>>>>>>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<swift-evolution@swift.org(mailto: > swift-evolution@swift.org) > > > >><mailto:swift-evolution@swift.org>(mailto:swift-evolution@swift.org > > > >><mailto:swift-evolution@swift.org>)(mailto:swift-evolution@swift.org > > > >><mailto:swift-evolution@swift.org>)(mailto:swift-evolution@swift.org > > > >><mailto:swift-evolution@swift.org>)>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 > > > >>>>>>>>>>swift-evolution@swift.org(mailto:swift-evolution@swift.org) > > > >><mailto:swift-evolution@swift.org>(mailto:swift-evolution@swift.org > > > >><mailto:swift-evolution@swift.org>)(mailto:swift-evolution@swift.org > > > >><mailto:swift-evolution@swift.org>)(mailto: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) > > > >><mailto:swift-evolution@swift.org>(mailto:swift-evolution@swift.org > > > >><mailto:swift-evolution@swift.org>)(mailto: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) > > > >><mailto:swift-evolution@swift.org>(mailto:swift-evolution@swift.org > > > >><mailto:swift-evolution@swift.org>)(mailto: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)<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)<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