[swift-evolution] Change `repeat` to loop indefinitely if no while clause is present

Tue May 10 17:51:41 CDT 2016

> On May 10, 2016, at 3:13 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
> 
> On Tue, May 10, 2016 at 3:30 PM, Tyler Cloutier via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> I’d actually say that I’m strongly in favor of allowing just a repeat keyword, although I wouldn’t support making 'while true’.
> 
> Firstly it reduces clutter
> 
> Can you explain what clutter you see? Unless I misunderstand what you're referring to, reducing the 10 letters in `while true` to the six letters in `repeat` is hardly "reducing clutter.”

I’m just referring to 'repeat {} while true’ -> 'repeat {}' 

>  
> and makes it very clear that the the code is just supposed to repeat.
> 
> I disagree here also. It is not very clear at all that the code is supposed to repeat indefinitely, not to any audience.
> 
> First, it would not be clear to users who are experienced in Swift and aware of this proposal. Code is meant to be read, and allowing the omission of a trailing clause to produce two very different behaviors means that it is not clear what `repeat {` means until you encounter the closing brace and check for what follows.

This is just as true of all types of loops. If I have 

repeat {
    ...
} while ...

I still have to scroll down to check the condition.

If I have 

while true {
    ...
}

I still have to scan the entire body for different ways of exiting the loop. 

> Moreover, what follows could be the keyword `while` on the following line, and in that case you cannot know whether the expression that follows `while` is the beginning of a new while loop until you encounter or don't encounter a new opening brace.

This is true, but it’s not ambiguous and any reasonable style would make it clear what the intension is. However, this does sound difficult for the compiler to parse, I will admit. This whole thing might be a moot point if can’t be integrated into the grammar. I don’t think I’m qualified to comment on the implications there.

> By contrast, `while true {` cannot be anything other than the beginning of an infinite loop. You already know that fact after reading 12 letters.
> 

As I’ve said above, this is not true. I can break out of the loop at any time.

> Second, it would not be clear to users migrating from another C-family language. `while true { }` is immediately understood by users of any other related language.

repeat as a keyword is already unfamiliar to users from other C-family languages. If they can grok the repeat-while loop, they can definitely understand repeat immediately.

> 
> Third, it would not be clear based on a knowledge of English. In common use, "repeat" does not mean repeat forever; it means to repeat once (i.e. do something twice). If I ask you to repeat something you just said, I should hope that you do not keep reciting it over and over until I tell you to stop.
>  
> Secondly it’s a very simple way of introducing new programmers to loops. It’s IMHO more clear to a new programmer that repeat will just repeat indefinitely vs while true.
> 
> I can speak to this a little bit, having introduced a new programmer to loops very recently and having done so in the past as well. I have not encountered anyone who has trouble with the *concept* of looping--i.e. the idea that the same code can be run over and over.
> 
> Where things get tricky is the difficulty of mastering the syntax of the while loop and, more problematic, the syntax of the classic for;; loop. Introducing a simple way to make something repeat forever does not solve this learning hurdle, because students will continue to have to contend with these other types of loops in order to be productive in the language.

You’re saying that we should not have a simple syntax because they will eventually have to understand more complex syntax? Or am I misunderstanding?

> A special syntax for repeating forever is especially unhelpful because it is just functional enough that a discouraged student may choose to avoid learning other types of loops and instead combine the infinite loop with if, continue, and break.
>  
> Lastly, this isn’t the first time this has been brought up on this list and there was previously discussion about the fact that when people see the repeat keyword that it should naturally repeat indefinitely unless a where clause is specified.
> 
> I do believe that this is the first time this suggestion has been introduced to the list. I do not recall any previous discussion focused on infinite loops; they have been about repeating a finite number of times, using proposed syntax such as `repeat 3 times { }` or variations on that theme.
>  

Yes, that's the discussion I was referring to, and you can see that proponents had very similar arguments to the one I’m presenting now.

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001144.html

> I also think the concern that an accidental infinite loop is any greater than it is currently.
> 
> Code gets refactored and edited. We're discussing on another thread changing the rules about dangling commas in parameter lists for that very reason. If you try to move a block of code with a repeat...while loop but accidentally leave behind the last line, this syntax will cause you grief.

This is also true of repeat-while loops with more than one condition

repeat {

} while this 
&& that

Should we require parentheses on repeat-while loops to avoid this? Or should we err on the side of less noisy syntax?

Tyler

>  
> Tyler
> 
> 
> 
>> On May 10, 2016, at 1:09 PM, Erica Sadun via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> I do not see sufficiently measurable benefits to this proposal to add it to the language. 
>> It's easy enough to roll your own `repeatForever` function with trailing closure.
>> 
>> I also want to thank you for bring it up on-list. Not every idea is right for Swift but it's
>> always refreshing to see innovative thoughts added to the discussion. Please do not be 
>> discouraged by the generally negative feedback on this particular idea.
>> 
>> -- Erica
>> 
>>> On May 10, 2016, at 1:27 AM, Nicholas Maccharoli via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>> Swift Evolution Community,
>>> 
>>> Currently writing an infinite loop in swift looks either something like this:
>>> 
>>>     while true {
>>>         if ... { break }
>>>         //...
>>>     }
>>> 
>>> Or this:
>>> 
>>>     repeat {
>>>         if ... { break }
>>>         //...
>>>     } while true
>>> 
>>> But I think it might be best to change the syntax / behaviour of `repeat` to loop 
>>> indefinitely if no trailing while clause is present:
>>> 
>>>     repeat {
>>>         if ... { break }
>>>         //...
>>>     }
>>> 
>>> while still allowing a trailing `while` clause as in:
>>> 
>>>     repeat { 
>>>         foo += bar
>>>     } while foo.count < limit 
>>> 
>>> I also want to propose that it should be a compile time error to use single `Bool` constants as while loop conditions, so no more `while true { ... }` it would become `repeat { ... }`
>>> 
>>> I was thinking of drafting a short proposal if there was enough positive feedback. 
>>> 
>>> How does it sound?
>>> 
>>> - Nick 
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160510/300d6c84/attachment.html>