Why no (auto foo = bar) in while loops?

[Timon Gehr]

On 08/25/2011 10:51 PM, Steven Schveighoffer wrote:
 > On Thu, 25 Aug 2011 12:21:19 -0400, Timon Gehr <timon.gehr at gmx.ch> wrote:
 >
 >
 >>
 >> I usually replace code like this:
 >>
 >> x++;
 >> if(x < 100)
 >> {
 >> // use x
 >> }
 >>
 >> with this:
 >>
 >> if(++x < 100) {
 >> // use x
 >> }
 >>
 >> so the logical mapping to while would map this:
 >>
 >> x++;
 >> while(x < 100)
 >> {
 >> // use x.
 >> }
 >>
 >> to this:
 >>
 >> while(++x < 100) {
 >> // use x.
 >> }
 >>
 >>
 >> But it looks like every time through the loop x gets incremented.
 >> That's not what I'd want. At the very least, it's confusing
 >> semantics one way or the other.
 >>
 >> If you use the construct in the *init* section of a for loop, it reads
 >> the same as the if statement, since that part is only executed once.
 >>
 >> The while loop just doesn't fit the model. Let's ditch the while loop.
 >
 > Not relevant, you are not declaring a variable in your example.

It was _the whole point_ that I am not declaring a variable in my 
example. Our two examples are equivalent in what they are saying on a 
conceptual level. Whether the condition contains a declaration or an 
increment operation does not matter.

 > The
 > benefit of using the auto x = y is that you can move the declaration of
 > the variable, which is used only during the loop, into the loop 
statement.

The benefit of using the auto x = y is that you can declare a new 
variable inside the condition, plus useful scoping.

 >
 > I have written loops like this:
 >
 > bool found = false;
 > while(!found)
 > {
 > // things that might set found to true
 > }

for(;;) {
     ... break; ...
}

or even

for(bool found=false;!found;){
     // things that might set found to true
}


 >
 > There is also this construct, which is what you are arguing for:
 >
 > bool continueloop;
 > while(continueloop = someComplexFunction())
 > {
 > // use continueloop as rvalue in places
 > }
 >

I am not arguing for this esoteric case, I wouldn't use a boolean flag, 
but a reference or pointer that is then guaranteed to be non-null inside 
each loop body execution. Pragmatic and consistent with how it would 
normally be used in if.

 > So there are legitimate cases for while(auto x = y) being a shortcut for
 > both behaviors, hence the confusion.

There is really no legitimate reason for while(auto x = y) being a 
shortcut for the first.

 >
 > I agree your case yields more fruit, since I think the above is actually
 > invalid (can't use = as a boolean expression), but it doesn't stop me
 > from being confused about whether the initialization happens once or
 > every time. It just reads like it happens once to me, even if it happens
 > every loop. That confusion isn't there for if statements or for loops.
 >

Why does the _loop condition_ read like it happens only once to you? I 
don't get that.


for(init; condition; statement){}
while(    condition           ){}

The init part of for is irrelevant for this discussion because it does 
not exist in while. conditions work for both kinds of loops in the same 
way: They are executed and checked before the loop body is run. The body 
of an if is only executed once, therefore the condition is only executed 
and checked once. If there is an inline-declaration or not does not 
matter for the execution semantics, and it *WOULD* be confusing if it was.