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

[Tony Allevato]

On Fri, Jun 24, 2016 at 11:30 AM Xiaodi Wu via swift-evolution <
swift-evolution at swift.org> wrote:

> On Fri, Jun 24, 2016 at 6:37 AM, William Shipley <wjs at mac.com> wrote:
>
>> On Jun 23, 2016, at 11:04 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>>
>>
>> Not a practitioner of 80-character line limits, I take it?
>>
>>
>> I don’t understand why anyone wouldn’t just let Xcode do the wrapping for
>> most cases. I’ll add newlines if I think it adds to clarity, but in general
>> I don’t want to code like i’m still on a Wyse WY-50.
>>
>
> Of course, to each their own style--I certainly wouldn't want Swift to
> force everyone to write lines of certain lengths. But 80-character lines is
> a common style, and I would say that a corollary of "to each their own" is
> that Swift's grammar should be usable and useful whether or not you adhere
> to such style choices.
>
> If the chief advantage of `where` is that it (quoting someone above)
> allows one to "understand as much as possible about the control flow of
> the loop from a single line of code," then we ought perhaps to question its
> appropriateness when the majority of its benefits [by which I mean, based
> on your examples and Sean's, more than half of the instances in which it is
> used] cannot be realized in a very common coding style.
>

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
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160624/1950f984/attachment.html>