<div style="white-space:pre-wrap">The equivalent in Swift would be .filter(), and you're free to use it if you prefer to express yourself that way.<br><br>Notice how these are almost never paired with loops. It's like mixing chocolate and steak.<br></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Jun 14, 2016 at 8:50 AM plx via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> On Jun 13, 2016, at 10:26 AM, Erica Sadun via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
><br>
><br>
>> On Jun 13, 2016, at 9:23 AM, let var go via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
>><br>
>> I am 100% with Charlie on this. Expressiveness has to do with the *effectiveness* of conveying a thought or a feeling.<br>
>><br>
>> Keep "where". It is expressive. It conveys a specific idea effectively and concisely.<br>
><br>
> For those of you in favor of retaining `where`, how do you feel about adding `while`, `until`, `unless`, etc?<br>
<br>
In the interest of advancing the “what kind of language would I prefer swift become?”, here are my final thoughts on this topic:<br>
<br>
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.<br>
<br>
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.).<br>
<br>
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:<br>
<br>
<a href="https://en.wikipedia.org/wiki/Comparison_of_programming_languages_(list_comprehension)" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/Comparison_of_programming_languages_(list_comprehension)</a><br>
<br>
…(note that “comprehension syntax” isn’t quite the same thing as “list comprehensions”, but for “comparative syntax” purposes that link should be sufficient).<br>
<br>
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.<br>
<br>
Here’s a toy example:<br>
<br>
// with a comprehension-like syntax<br>
// outside loop: “what items do we care about?"<br>
for visitor in queue where visitor.hasTicket until venue.isFull {<br>
// inside loop: “…and what do we do with them?"<br>
venue.admit(visitor)<br>
}<br>
<br>
…which to my eyes paraphrases more-or-less how I’d describe what we’re doing:<br>
<br>
- “keep admitting visitors with tickets until the venue is full”<br>
<br>
…whereas without it, you get something like this:<br>
<br>
// without comprehension-style syntax<br>
// outside loop: where, mechanically, are we sourcing items from<br>
for visitor in queue {<br>
// inside loop: muddled mix of filtering, app logic, and flow-control<br>
// filtering:<br>
guard visitor.hasTicket else { continue }<br>
// app logic:<br>
venue.admit(visitor)<br>
// flow-control:<br>
if venue.isFull { break }<br>
}<br>
<br>
…which *is* closer to the underlying mechanics, but paraphrases more like something you'd see in a badly-translated 80s VCR programing manual:<br>
<br>
- “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.”<br>
<br>
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?”<br>
<br>
So that’s what I like about comprehension-like constructs.<br>
<br>
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.<br>
<br>
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”:<br>
<br>
- 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<br>
- if a “comprehension” construct is definitively-rejected, at least I can keep using something I like until the hammer drops<br>
<br>
><br>
> -- E<br>
><br>
> _______________________________________________<br>
> swift-evolution mailing list<br>
> <a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div>