[swift-evolution] [Review] SE-0007 Remove C-style for-loops with conditions and incrementers

[Tyler Cloutier]

David, the 

if true {
        
}

scope mechanism can be accomplished with 

do {
        
}

Nonetheless, I would agree that the point remains that the while loop equivalent is more difficult to read (and write) and maintain. I would argue perhaps somewhat controversially that the loop that should go is the while loop, as it has a strict subset of the functionality of the C style for loop.

Why not allow each of the three expressions to be optional?

for var i = 0 while i < 5 step i += 1  {

or 

while someCondition() { 

or 

for var i = 0 step i += 1 {

or 

for var i = 0 while someOtherCondition() {


The mechanical conversion of for to while that you proposed below demonstrates that there is a purpose to the C style for loop features, why not allow them to be optional?

Tyler

> On Dec 11, 2015, at 9:18 AM, David Owens II via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> On Dec 11, 2015, at 8:27 AM, Erica Sadun via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> As for c-style-for vs while, the two are mechanically convertible.
> 
> This is provably false and has been demonstrated, but here is an example of it again: 
> 
>     var sum = 0
>     for var i = 10 /* expr1 */; i > 0 /* expr2 */; i -= 1 /* expr3 */ {
>         if i % 2 == 0 { continue } // statement
>         sum += 1                   // statement
>     }
>     print(sum)
> 
> 
>     var sum = 0
>     var i = 10 // expr1
>     while i > 0 /* expr2 */ {
>         if i % 2 == 0 { continue } // statement
>         sum += 1                   // statement
>         
>         i -= 1 // expr3
>     }
>     print(sum)
> 
> It’s not just a mechanical conversion; consideration for early loop-exits and continuations need to be made as well. The rote conversion for the while version above is an infinite loop. Not only that, expr1 now leaks variables into a scope that is no longer contained within the loop. 
> 
>> Where heavy performance is not required, for-in is more readable, maintainable, and optimizable to a sufficient extent that I do not see it as a bar to conversion.
> 
> This is a pure philosophical difference that I don’t think we’ll agree on. The injection of types are required to make for-in constructs work with the hope that the optimizer can clean all of this up later. This is fundamentally the same claim that C++ makes with it’s zero-cost abstraction. Mike Action has some great talks on YouTube that demonstrate many of the real-world problems he runs into.
> 
> Should the for ;; construct be used for all loop iteration? No, I don’t think so. But we shouldn’t make the claim that the while-loop is an equivalent form, because it’s not. Can it be used to mimic the functionality? Of course, but not in a mechanical conversion like you suggest. Care has to be taken that the statements don’t essentially branch and an artificial scope needs to be added. 
> 
>     if true {
>         var sum = 0
>         var i = 10 // expr1
>         while i > 0 /* expr2 */ {
>             if i % 2 == 0 { continue } // statement
>             sum += 1                   // statement
>         
>             i -= 1 // expr3
>         }
>     }
>     print(sum)
> 
> And then there is this:
> 
>> Performance is definitely a consideration; we already reverted a pull request that remove C-style fors from the standard library. I believe Andy is currently looking into where the regressions come from. stride(...) performing poorly seems like something we should fix regardless, since that's arguably the idiomatic way to write such loops and ought to perform well. I agree we should investigate ways to ensure common loops over ranges or strides perform reasonably at -Onone if we move forward with this.
> 
> -David
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151211/5347c41e/attachment.html>