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

[Xiaodi Wu]

On Sun, Jun 12, 2016 at 8:28 AM, Thorsten Seitz <tseitz42 at icloud.com> wrote:

>
> Am 12.06.2016 um 00:16 schrieb Xiaodi Wu <xiaodi.wu at gmail.com>:
>
> On Sat, Jun 11, 2016 at 5:07 PM, Thorsten Seitz <tseitz42 at icloud.com>
> wrote:
>
>>
>>
>> Am 11.06.2016 um 23:52 schrieb Xiaodi Wu <xiaodi.wu at gmail.com>:
>>
>> On Sat, Jun 11, 2016 at 3:31 PM, Thorsten Seitz <tseitz42 at icloud.com>
>> wrote:
>>
>>>
>>>
>>> Am 11.06.2016 um 21:57 schrieb Xiaodi Wu <xiaodi.wu at gmail.com>:
>>>
>>> On Sat, Jun 11, 2016 at 2:50 PM, Thorsten Seitz <tseitz42 at icloud.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> Am 10.06.2016 um 17:22 schrieb Erica Sadun via swift-evolution <
>>>> swift-evolution at swift.org>:
>>>>
>>>>
>>>> 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" :
>>>>
>>>>
>>>> How many of the 950 "for in loops" use a guard with continue? Only
>>>> these can be compard with the "for in where loops".
>>>>
>>>
>>> That is a different argument, I think, from the one Erica is making. The
>>> data you're asking about would answer the question, "How often do stdlib
>>> authors prefer `guard` over `where`?" That is an interesting question,
>>> certainly.
>>>
>>>
>>> It is the relevant question to ask when deciding whether `where` should
>>> be better replaced by `guard`. And it should be qualified by asking whether
>>> the respective author did know about `where`. I wouldn't want a language to
>>> be designed by looking at usage examples of inexperienced users...
>>>
>>>
>> Here, I disagree with you vehemently. We should absolutely take into
>> consideration how inexperienced users work with the language. A language
>> that ignores the struggles and pain points of those who are less
>> experienced is one that will quickly find itself lacking in users.
>>
>>
>> You don't want to tell me in earnest that discovering and understanding
>> `where` in for loops are stumbling blocks for beginners in a language
>> containing generics, associated types, existentials, value vs. reference
>> types etc.?
>>
>
> I do. I challenge you to find an introductory text that teaches generics,
> associated types, existentials, or even value vs. reference types before it
> introduces `for` loops or `if` (and `guard`).
>
>
> My point was that someone who endeavors to learn a language like Swift
> which does include all these things, will not falter when he stumbles upon
> `where` in a `for` loop.
>

I'm not sure how you can come to this conclusion that a new user *will not*
falter over this concept or that simply because a language includes more
difficult concepts. I have seen bright students struggle with `i = i + 1`
when learning to code in languages with advanced concepts. (See if you can
guess what is confusing about `i = i + 1`.) Know that if a user cannot
master loops, then he or she cannot write very much of consequence in a
language at all. But a user who does not understand generics, associated
types, existentials, or value vs. reference types can still very well find
some good use for Swift in the meantime.

He might be surprised for a moment (when coming from other languages but
> probably not when Swift is his first language, nor when he already knows
> languages like C# or SQL) but not more.
>
> -Thorsten
>
>
>
>
>>
>> -Thorsten
>>
>>
>>> I think Erica's point is that what Vladimir earlier called the "simple,
>>> common" case may be simple but isn't actually common. I did a quick GitHub
>>> search earlier today (and the tools aren't there, afaik, for an accurate
>>> regexp search), but what I noticed on a random, not-statistically-sound
>>> sampling was that uses of `continue` and `break`, when they do occur inside
>>> a for loop (which isn't always), actually tend to happen after some work
>>> has been done at the top of the loop. These wouldn't be replaceable by a
>>> `where` clause. Moreover, I noticed an appreciable share of `return` and
>>> `fatalError()` calls from inside the loop, which surprised me; I had
>>> assumed I'd find mostly `break` or `continue`, but even when I did find
>>> those it was as likely as not to be accompanied by logging. These again
>>> preclude refactoring into `where`.
>>>
>>>
>>> Logging hints at logic used for filtering out data errors. That's a good
>>> usage for `guard` as opposed to `where`. The latter is about logic, not
>>> about error handling.
>>>
>>> -Thorsten
>>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160612/cb3151fa/attachment.html>