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

Tyler Fleming Cloutier cloutiertyler at aol.com
Wed May 11 01:31:17 CDT 2016


> On May 10, 2016, at 11:12 PM, Nicholas Maccharoli <nmaccharoli at gmail.com> wrote:
> 
> Hello ​Swift Evolution community,​
> 
> Thank you so much for all the important feedback, this thread became more lively than I initially hoped for!
> 
> First let me address Xiaodi Wu's questions from earlier: 
> 
> What is your motivation for this change?
> 
> After thinking about it maybe I overreacted with wanting to phase out `while true`.
> I know `while true` is a programming idiom found in most languages but I personally think expressions testing a single `Bool` literal
> like `while true { ... }` are just as tasteless as directly using `true` as in `if true { ... }` and might possibly signify that swift needs a better construct to express an infinite loop.
> 
> So after reading this thread's feedback I'm changing my tone and think we should leave `while true` alone and let it continue to be
> a valid way of expressing an infinite loop but maybe at the same time we should think of adding a more Swifty alternative.
> 
> As a source of inspiration I really like rust's solution of `loop { ... }`: https://doc.rust-lang.org/book/loops.html <https://doc.rust-lang.org/book/loops.html>
> but Swift already has a `repeat` statement so I initially thought of modifying the behaviour of `repeat` to allow omitting the trailing `while true` as to not bloat Swift with a new keyword.

Very interesting that there is precedence in Rust. 

> 
> What problems are solved by forbidding `while true`?
> 
> ​As I said above, after thinking about it again I think we should keep `while true` but I want to talk about a possible issue with the
> `while true` idiom:
> 
> ​    ​let foo: Int​ 
>     ​while true { foo = 5; break }
> ​    ​print(foo)
> 
> ​The above code will error out with the message "Constant 'foo' used before being initialized"​
> `while true` will always enter the body of the loop at least once but since `while` is a conditional statement this error occurs
> whereas this code works just fine:
> 
>     let foo: Int
>     repeat { foo = 5; break } while true
>     print(foo)
> 
> since `repeat` will unconditionally enter the repeat block at least once. 
> So I think my initial idea can be broken up into two distinct parts.
> 
> Part I: add a `while true` alternative
> ----------------------------------------------------------------------------------------
> 
> So for the `while true` idiom replacement I want to propose adding something like a `loop { }` construct or possibly modifying the `repeat` keyword to take a statement modifier such as `sustained repeat { ... }`

I’m of the opinion that if it requires an additional keyword for this small a feature it’s probably not worth it.

> 
> 
> Part II: change `repeat` statement ordering OR  `while` statement modifier
> ----------------------------------------------------------------------------------------
> 
> Idea #1:
> 
> Add a statement modifier to `while` that would ignore the `while` loop's condition only
> on the first run-through.
> Not too sure on the naming of the statement modifier but maybe something something like `after while foo > bar { ... }` 
> 
> `after` would signify that the while loops condition would be checked only after the first iteration. 
> 
> Idea #2:
> 
> change `repeat { ... } while ...` to `repeat while ... { ... }` so that the loop condition can be seen upfront in long blocks, 
> adding a `repeat` in front of the while loop would ensure that the loop runs once before evaluating the loop condition.
> This would essentially remove the repeat keyword and make it a statement modifier like the above written `after`. 

I’m not really following you here. 

With regards to #1, the repeat-while/do-while style loops are very familiar to C programmers and programmers generally. I don’t think the "after" keyword would serve to reduce confusion. 

Same with #2. That syntax does seem to indicate in any way that the loop will run before the condition is checked. As far as I am aware, this runs counter to all while loop constructs in essentially all languages that have them.

> 
> Sorry for dragging this out a little after all the great feedback but does either idea have any appeal to the Swift community?
> 
> Thanks!
> 
> - Nick 
> 
> 
>  
> 
>  
> 
>  
> 
> 
> 
> 
> 
> All the best,
> 
> Nicholas
> 
> Linked in:
> http://lnkd.in/328U22 <http://lnkd.in/328U22>
> 
> 
> On Tue, May 10, 2016 at 4:39 PM, Xiaodi Wu <xiaodi.wu at gmail.com <mailto:xiaodi.wu at gmail.com>> wrote:
> On Tue, May 10, 2016 at 2: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 
>  
> What is your motivation for this change?
>  
> 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 { ... }`
> 
> What problems are solved by forbidding `while true`?
>  
> 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>
> 
> 
> 
> 
> All the best,
> 
> Nicholas
> 
> Linked in:
> http://lnkd.in/328U22 <http://lnkd.in/328U22>
> 
> 
> On Wed, May 11, 2016 at 10:11 AM, Tyler Cloutier via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> 
> > On May 10, 2016, at 5:56 PM, Chris Lattner <clattner at apple.com <mailto:clattner at apple.com>> wrote:
> >
> >
> >> On May 10, 2016, at 4:13 PM, Cole Campbell via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> >>
> >> 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.
> >
> > Right, this is the downside that I see with “repeat {}”.
> 
> 
> Not to beat a dead horse, but isn’t this also true of
> 
> repeat {
> 
> } while true
> 
> and
> 
> while true {
>    ...
>    ...
>    if condition {
>         break
>    }
> }
> 
> >
> >> while true { } is preferable in that regard, but a compromise that I saw mentioned is:
> >>
> >> repeat forever { }
> >
> > This would require taking “forever” as a keyword if we supported “repeat N {", something we wouldn’t want to do.
> >
> > Another option is to make it a statement modifier, which wouldn’t require taking it as a keyword (but also doesn’t read as well):
> >
> > forever repeat { }
> >
> >
> > Personally, I don’t see this as a big enough improvement over “while true” to be worth introducing complexity for.
> >
> 
> If you are referring to “forever", I also don’t think that adding a new keyword is an improvement over “while true”.
> 
> > -Chris
> 
> _______________________________________________
> 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/62841ad6/attachment.html>


More information about the swift-evolution mailing list