> On 10 Jun 2016, at 21:53, Xiaodi Wu <[email protected]> wrote:
>
> I had quite a visceral reaction to the example given at one point:
>
> for number in fibonacci where number % 2 == 0 while number < 4_000_000 {...}
>
> This, IMO, is long enough to cause a heart attack.
This is not what’s being discussed though, that’s a separate feature request
and I’ve already pointed out that I’m not that comfortable with allowing both
where and while on the same line. That said, it’s worth remembering that syntax
highlighting doesn’t always carry into the mailing list; in Xcode the
colouration of “where” makes it a pretty significant separator between the loop
and the where clause, which a “while” clause would presumably do too.
Although it’s not IMO that bad of an example (though I’m not sure I’d actually
write something like that personally), I feel it’s worth pointing out that when
using the guard alternatives there is absolutely nothing (besides common
decency) stopping me from writing the following if I want to:
for number in fibonacci { guard number % 2 == 0 else { continue };
guard number < 4_000_000 else { break }; … }
Compared to that the for in where while variant is very elegant.
The appeal of where clauses to me is that they are a neat way to handle simple,
common cases. In my own code the cases where I’d like to see a “while” variant
would not be used in combination with where, in fact I can’t currently find any
instance in my code where I have both a guard continue and a guard break that
could be rolled into a single where while condition (I have maybe three loops
that have both of these, but when I do they’re not both right at the start).
That said, this is not an argument for removing where, it’s an argument for
refining the proposal for a “while” variant, e.g- allow only one of these per
loop (which also solves any confusion around the order they are evaluated in).
> Regarding some of the numbers that have come up about for in vs for in where
> loops (in my own code I’m close to maybe of 20% of my for in loops using it),
> it’s important to recognise that the use of the where clause isn’t well
> advertised. When I started out with Swift I only knew that it could be used
> on cases in a switch statement, and later that it was used with complicated
> generics. It wasn’t until I joined the mailing list that I found out it could
> be used with conditional bindings and loops, but when I did I started using
> it almost immediately.
>
> Since it is so obscure, I think it'd be fair to say that the feature is not
> fundamental to Swift's "character" or "style." In fact, I understand that it
> was added only later. I could buy the argument that, if advertised widely,
> people would find ways to use it more widely and perhaps even generally
> correctly.
The latter is what I believe; if I’d known about it sooner I would have used it
sooner, but the Swift introduction I followed only seemed to use it on case
statements. I found out about the other uses later for generics when I ran into
the limitations of very basic type-only generics, and later still for
conditional binding (at which point I tried it on while and for loops too).
The same is true of pattern matching btw; I didn’t learn about that until I
joined the mailing list either, but I wouldn’t want rid of that feature either
as now that I’m aware of it I find it very useful. Given that the two features
are kind of linked since “where" was apparently being introduced with a view
towards more powerful pattern matching, it’d be interesting to find out what
that more powerful pattern matching was going to look like.
Whether either feature became vestigial or not in terms of their intended
design, both are useful constructs that I think just need to be championed more._______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
