I agree that repeat { } is ambiguous because you have to look to the end for a
while clause to determine if it's infinite or not. while true { } is preferable
in that regard, but a compromise that I saw mentioned is:
repeat forever { }
That is immediately clear that it is infinite like while true { } but reads
better in English. And it's a nice extension of repeat N { }, which is
something I wouldn't mind seeing being added to the language.
So +1 for repeat N { }, +1 for repeat forever { }, -1 for repeat { }.
> On May 10, 2016, at 6:02 PM, Tyler Cloutier via swift-evolution
> <[email protected]> wrote:
>
>
>> On May 10, 2016, at 3:59 PM, Xiaodi Wu <[email protected]> wrote:
>>
>>> On Tue, May 10, 2016 at 5:56 PM, Tyler Cloutier <[email protected]>
>>> wrote:
>>>
>>>> On May 10, 2016, at 3:13 PM, Xiaodi Wu <[email protected]> wrote:
>>>>
>>>>> On Tue, May 10, 2016 at 3:30 PM, Tyler Cloutier via swift-evolution
>>>>> <[email protected]> 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."
>>>>
>>>>> 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. 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. By
>>>> contrast, `while true {` cannot be anything other than the beginning of an
>>>> infinite loop. You already know that fact after reading 12 letters.
>>>>
>>>> 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.
>>>>
>>>> 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.
>>>> 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.
>>>
>>> I’d also like to point out Chris’ comments on the
>>>
>>> repeat X {
>>>
>>> }
>>>
>>> discussion.
>>>
>>> “
>>> This is a very valid use case.
>>>
>>> FWIW, “repeat N {}” was originally designed and scoped into the Swift 2
>>> implementation of the feature, but was cut due to schedule limitations.
>>> There is precedent for this sort of feature in many teaching oriented
>>> languages (e.g. Logo).
>>>
>>> I’d say that the pro’s and con’s of this are:
>>>
>>> + Makes a simple case very simple, particularly important in teaching.
>>> + Even if you aren’t familiar with it, you can tell at first glance what
>>> the behavior is.
>>> - It is “just syntactic sugar”, which makes the language more complex.
>>> - It is a very narrow feature that is useful in few practical situations.
>>>
>>> -Chris
>>> “
>>>
>>> In this case, I would say it’s not making the language any more complex
>>> given that repeat-while is a current construct. Admittedly it is a very
>>> narrow feature, but it’s also a small one.
>>
>> For the reasons I outlined above, I'd be +1 for `repeat N` and -1 for this
>> case.
>
> That’s fair enough. :)
>
> But surely you’ll admit that if
>
> repeat N {
>
> }
>
> was valid, then repeat { } follows as the logical repeat indefinitely syntax,
> no?
>
>
>>
>>>
>>>>
>>>>> 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.
>>>>
>>>>> 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.
>>>>
>>>>> Tyler
>>>>>
>>>>>
>>>>>
>>>>>> On May 10, 2016, at 1:09 PM, Erica Sadun via swift-evolution
>>>>>> <[email protected]> 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
>>>>>>> <[email protected]> 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
>>>>>>> [email protected]
>>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>>>
>>>>>> _______________________________________________
>>>>>> swift-evolution mailing list
>>>>>> [email protected]
>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> swift-evolution mailing list
>>>>> [email protected]
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
