[swift-evolution] [Pitch] Retiring `where` from for-in loops

Haravikk swift-evolution at haravikk.me
Sat Jun 11 06:42:17 CDT 2016


> On 10 Jun 2016, at 21:53, Xiaodi Wu <xiaodi.wu at gmail.com> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160611/22d9352f/attachment-0001.html>


More information about the swift-evolution mailing list