[swift-evolution] SE-0105: Removing Where Clauses from For-In Loops

[Jed Lewison]

I think this is an excellent argument for keeping where — I was tempted to make a hand waving argument in favor of keeping where, but I think you made the case as well as it can be made. (I suppose you could even argue that there are really 7 components to the other construct since you can have continue, break, or return, but that just underscores your point.)

I also agree with your points about using lazy.filter instead.

BTW, the project I’m currently working on has about 10-15 for loops that use where.

Net/net: I’m a -1 on the proposal.

> On Jun 24, 2016, at 11:38 AM, Tony Allevato via swift-evolution <swift-evolution at swift.org> wrote:
> 
> IMO, we shouldn't be talking about "a single line of code" so much as "a single cohesive construct". What's important to me isn't the line length or whether the "where" part has to wrap onto another line, it's the number of potentially divergent constructs I have to parse mentally in order to determine the meaning of the loop.
> 
> With "for-in-where", it's three:
> 
>     for item(1) in someCollection(2) where someCondition(3)
> 
> With the alternatives suggested using if/guard/continue/break, it's more than that:
> 
>     for item(1) in someCollection(2) {
>         [if | guard...else](3) someCondition(4) {
>             [continue | break](5)
>         }
>     }
> 
> I have to be more careful now interpreting the meaning of this loop because both or either of if/guard or continue/break can invert its meaning, where was "for-in-where" is concise and clear.
> 
> Doing .lazy.filter{...} is slightly cleaner than this, but still suffers from the disadvantage that it's very easy for newcomers to leave out the "lazy" part and accidentally write poorly performing code, and to the argument that "where" is considered confusing by some users, I would argue that it's easier to explain how it works than why "lazy" is necessary in this context.
>  
> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160626/b01f603c/attachment.html>