Thanks for the great way of breaking it down. The issue I see is that it is quite easy to incorrectly assume what (3) and (5) are below. Some assume it breaks, others that it just skips and continues.
So in my mind there’s nothing wrong with wanting something that can be written on one line together with the `for in`. The problem is this particular syntax is ambiguous. Patrick > On 25 Jun 2016, at 4:38 AM, Tony Allevato via swift-evolution > <[email protected]> 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 [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
