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]> 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
> > > >>>>>><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
> > > >>>><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
> > > >><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
> > <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
