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

[Xiaodi Wu]

The equivalent in Swift would be .filter(), and you're free to use it if
you prefer to express yourself that way.

Notice how these are almost never paired with loops. It's like mixing
chocolate and steak.

On Tue, Jun 14, 2016 at 8:50 AM plx via swift-evolution <
swift-evolution at swift.org> wrote:

>
> > On Jun 13, 2016, at 10:26 AM, Erica Sadun via swift-evolution <
> swift-evolution at swift.org> wrote:
> >
> >
> >> On Jun 13, 2016, at 9:23 AM, let var go via swift-evolution <
> swift-evolution at swift.org> wrote:
> >>
> >> I am 100% with Charlie on this. Expressiveness has to do with the
> *effectiveness* of conveying a thought or a feeling.
> >>
> >> Keep "where". It is expressive. It conveys a specific idea effectively
> and concisely.
> >
> > For those of you in favor of retaining `where`, how do you feel about
> adding `while`, `until`, `unless`, etc?
>
> In the interest of advancing the “what kind of language would I prefer
> swift become?”, here are my final thoughts on this topic:
>
> For those particular keywords, I’d prefer having them (or equivalents).
> I’m not sure if I’d prefer having *all* of them—`where/unless` and
> `while/until`—or just one from each “pair”…I could go either way.
>
> As a general consideration, I’d be in favor of having them b/c I’d really
> like Swift to have a comprehension-style construct (and associated syntax
> etc.).
>
> Comprehension syntax is IMHO pretty common outside the C family—within the
> C family really only C# has something like it—and in general comprehension
> syntax has pretty similar structure from language to language. This link
> illustrates the syntax for 28 languages’  comprehension constructs, so it
> isn’t a bad overview:
>
>
> https://en.wikipedia.org/wiki/Comparison_of_programming_languages_(list_comprehension)
>
> …(note that “comprehension syntax” isn’t quite the same thing as “list
> comprehensions”, but for “comparative syntax” purposes that link should be
> sufficient).
>
> For me the appeal of “comprehension syntax” is that it allows writing code
> that feels more “semantic” than “mechanical”, and that paraphrases much
> closer to the intended meaning.
>
> Here’s a toy example:
>
>   // with a comprehension-like syntax
>   // outside loop: “what items do we care about?"
>   for visitor in queue where visitor.hasTicket until venue.isFull {
>     // inside loop: “…and what do we do with them?"
>     venue.admit(visitor)
>   }
>
> …which to my eyes paraphrases more-or-less how I’d describe what we’re
> doing:
>
> - “keep admitting visitors with tickets until the venue is full”
>
> …whereas without it, you get something like this:
>
>   // without comprehension-style syntax
>   // outside loop: where, mechanically, are we sourcing items from
>   for visitor in queue {
>     // inside loop: muddled mix of filtering, app logic, and flow-control
>     // filtering:
>     guard visitor.hasTicket else { continue }
>     // app logic:
>     venue.admit(visitor)
>     // flow-control:
>     if venue.isFull { break }
>   }
>
> …which *is* closer to the underlying mechanics, but paraphrases more like
> something you'd see in a badly-translated 80s VCR programing manual:
>
> - “Start considering visitors. If the visitor doesn't have a ticket, move
> on to the next visitor. Otherwise, admit the visitor. If the venue is full,
> stop considering visitors.”
>
> Sure, they’re both equivalent—and even in the 80s, some people managed to
> program their VCRs!—but given the option I’d strongly prefer to write in
> the first style; I like having a clean segregation between “what items are
> of interest?” and “what do we do with them?”
>
> So that’s what I like about comprehension-like constructs.
>
> The current `for-in-where` is a bit of an anomaly; it could be grown into
> something a little richer—`for _ in _ where _ while _`  and/or `for _ in _
> where _ until _` (etc.).—or it could be dropped and some better construct
> proposed.
>
> But, my personal preference would be to keep it around until either the
> richer construct is available or definitively declared as “not swift-y, not
> happening”:
>
> - if a “comprehension” construct is approved, an automatic migrator would
> likely do a *much* better job translating those `for _ in _ where` loops
> than it’d do with their more-imperative equivalents
> - if a “comprehension” construct is definitively-rejected, at least I can
> keep using something I like until the hammer drops
>
> >
> > -- E
> >
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution at swift.org
> > 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/20160614/2b5f14d5/attachment.html>