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

[Tony Allevato]

On Wed, Jun 22, 2016 at 9:12 PM Chris Lattner <clattner at apple.com> wrote:

> Hello Swift community,
>
> The review of "SE-0105: Removing Where Clauses from For-In Loops" begins
> now and runs through June 29. The proposal is available here:
>
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0105-remove-where-from-forin-loops.md
>
> Reviews are an important part of the Swift evolution process. All reviews
> should be sent to the swift-evolution mailing list at
>
>         https://lists.swift.org/mailman/listinfo/swift-evolution
>
> or, if you would like to keep your feedback private, directly to the
> review manager.
>
> What goes into a review?
>
> The goal of the review process is to improve the proposal under review
> through constructive criticism and contribute to the direction of Swift.
> When writing your review, here are some questions you might want to answer
> in your review:
>
>         * What is your evaluation of the proposal?
>

-1000. This is one of the features of Swift that I feel is incredibly
elegant and unique, providing a way to do basic filtering and iteration
without having to worry about lazy filtering or control flow statements.



>         * Is the problem being addressed significant enough to warrant a
> change to Swift?
>

No—in fact, there is no problem. The "where" notation is perfectly grounded
in mathematics and set theory and its meaning is clear.  "for x in y where
z" reads almost exactly like the set notation "{x ∈ y | z}" does aloud.

The fact that some users may be confused by this terminology is not a
reason to remove it from the language. Some users will be confused by many
concepts in programming languages. If that means this is considered an
"advanced" feature, so be it. We should be able to have a language that has
both basic features and advanced features, and when a new developer comes
across a feature they don't understand, they learn it, and then they know
it. This is not an insurmountable problem.

IIRC, this proposal was a follow-up to the removal of "where" in "if"
statements, but the two uses of the term are unrelated. In "if" statements,
"where" was used to separate let-bindings from other parts of the
conditional—it was not a filter over a collection and did not correspond to
existing mathematical terms of art. That's not the case here, and it feels
like surface-level consistency for consistency's sake.



>         * Does this proposal fit well with the feel and direction of Swift?
>

No. The alternatives are worse, IMO:

* Putting if/guard and continue at the front of the loop is more clutter
and expresses the concept in terms of control flow instead of sequence
filtration, when the latter is closer to expressing the semantics of what
the loop is doing. I would argue that it increases the mental load because
now I have to parse an "if" or a "guard", the condition, and the "continue"
to make sure that it's doing exactly what it's doing (and the fact that
"guard" could be used here means there is implicit negation that I have to
parse on top of that), whereas "where foo" is right there and immediately
unambiguous.

* Using .filter() many times requires that .lazy also be used in order to
be performant. In many cases, writing the naïve .filter() line will return
a new copied collection and users are likely to accidentally write code
that is slower than it should be.

The fact that it only elevates one particular control flow construct ("if x
else continue") doesn't seem relevant. It's a common case and the language
should simplify common cases when possible. As a matter of fact, I would
also be supportive of the "for x in y while z" that some other people have
offered for the same reason. While it's less based on set theory than
"where", it optimizes another common case.



>         * If you have used other languages or libraries with a similar
> feature, how do you feel that this proposal compares to those?

        * How much effort did you put into your review? A glance, a quick
> reading, or an in-depth study?
>

Read the proposal and followed the earlier discussion threads.


>
> More information about the Swift evolution process is available at
>
>         https://github.com/apple/swift-evolution/blob/master/process.md
>
> Thank you,
>
> -Chris Lattner
> Review Manager
>
>
> _______________________________________________
> swift-evolution-announce mailing list
> swift-evolution-announce at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution-announce
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160623/7d196acb/attachment.html>