I give my +1 to this feature, it allows you to be explicit about a for loop escape condition at the outset instead of it being contained within the loops logic making them easier to maintain. Also it reads extremely well.
> On Jun 7, 2016, at 5:20 AM, 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
