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

[plx]

> 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