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

[Thorsten Seitz]

> 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.?

-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/6f7022ca/attachment.html>