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

[Ryan Lovelett]

On Fri, Jun 10, 2016, at 11:49 AM, Erica Sadun via swift-evolution wrote:
>
>> On Jun 10, 2016, at 9:24 AM, Erica Sadun
>> <erica at ericasadun.com> wrote:
>>
>>
>>> On Jun 10, 2016, at 9:22 AM, Erica Sadun via swift-evolution <swift-
>>> evolution at swift.org> wrote:
>>>
>>>
>>>> On Jun 10, 2016, at 8:02 AM, Xiaodi Wu via swift-evolution <swift-
>>>> evolution at swift.org> wrote:
>>>>
>>>> On Fri, Jun 10, 2016 at 7:18 AM, Haravikk <swift-
>>>> evolution at haravikk.me> wrote:
>>>>>
>>>>>> * The word "where" does not consistently imply `break` or
>>>>>>   `continue`. In current Swift, `where` implies `break` in the
>>>>>>   context of a `while` loop and `continue` in the context of a
>>>>>>   `for` loop. Some users intuitively guess the correct meaning in
>>>>>>   each context, while others guess the wrong meaning. Therefore,
>>>>>>   the only way to learn for sure what `where` means in any
>>>>>>   context is to read the rulebook. That, by definition, means
>>>>>>   that this is unintuitive.
>>>>>
>>>>>
>>>>> This is an argument for renaming the where keyword on for loops to
>>>>> be more clear, or to somehow integrate continue/break to be more
>>>>> explicit about what the developer intends for it to do.
>>>>
>>>> Sure: I conclude that the keyword should be *either* removed *or*
>>>> reformed; both outcomes could address the issue.
>>>
>>> This is my stance as well and I reserve the right to flit between
>>> both choices until we've fully talked it through.
>>>
>>> One more data point.
>>>
>>> In the standard library there are just under 950 uses of "for in
>>> loops". There are 3 uses of "for in while" :
>>>
>>> private/StdlibUnittest/StdlibUnittest.swift.gyb:    for j in
>>> instances.indices where i != j {
>>> public/core/Algorithm.swift:  for value in rest where value <
>>> minValue {
>>> public/core/Algorithm.swift:  for value in rest where value >=
>>> maxValue {
>>>
>>> -- Erica
>> Actually a slight correction to that. I forgot to add the space after
>> "in" on the first search. It's just over 600 and 3. Among the 600 are
>> a few false positives but not many.
>>
>> -- E
> And to follow-up to myself once again, I went to my "Cool 3rd Party
> Swift Repos" folder and did the same search. Among the 15 repos in
> that folder, a joint search returned about 650 hits on for-in (again
> with some false positives) and not a single for-in-while use.
 
I have access to 3 closed-source enterprise applications, iOS 9 and 100%
Swift 2.2. Each of them respectively have one "for in loop"; each one
makes use of a "where" clause.
 
Two of the applications are maintained/written by someone other than
myself. I wanted to audit them to see if those developers used "for in"
correctly or incorrectly; indeed they were all correctly used to filter
an Array. Though I cannot rule out they did not stumble into correct use
of the `where` clause.
 
More food for thought. Looking at the Git history I realized one of them
actually was refactored from something that looked like:
 
let a = [3, 1, 2].sort()
a.filter({ $0 <= 2 }).forEach({ print($0) })
 
to
 
let a = [3, 1, 2].sort()
for i in a where i <= 2 { print(i) }
 
I'm reasonably confident when I say the developers of this code have
never heard of swift-evolution let alone participated in it.
 
Obviously this is anecdotal evidence. It could be that `where` clause
is "easy to understand" _or_ equally likely that our hiring process
does a great job of selecting a heterogenous population of developers
with certain backgrounds that lead to similar code when faced with
similar problems.
 
You know what strikes me about this whole argument? "[This argument] is
like a rocking chair: it gives [us] something to do but [does not get
us] anywhere". - Someone Else
 
If this is an example of the pressing/priority issues facing the Swift
language today then I say lets all take a long weekend to bask in the
glow of this momentous occasion. Then meet back here in 2 years.
 
Change it or do not change it. I do not imagine it matters either way in
5 years. That having been said though I do think this argument, and
others similar to it, are important because I think they run deeper than
the syntax. I think they speak to the ethos of this community. With that
I think we should think long and hard about this process and what it
speaks to in terms of precedence and our collective priorities.
 
>
> -- E
> _________________________________________________
> 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/20160610/f1df7bc5/attachment.html>