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

[Steven Schveighoffer]

On Thu, 25 Aug 2011 17:31:26 -0400, Timon Gehr <timon.gehr at gmx.ch> wrote:

> 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.

Except the declaration is not currently allowed in a while-loop
conditional expression.  Nor was it allowed in an if conditional
expression, until it was added.  Prior to that addition, it was necessary
to declare the variable outside the if statement in order to only call the
intializer once.

>
>  > 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 think you just said the same thing I did :)

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

This doesn't always work, you may need to delay exiting the loop.

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

This also works in your case too.  You can simply declare your variable,
then assign it in the condition.  Insert whatever case you wish there.

>
>
>  >
>  > 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.

Well, it was just a contrived example, not a full-fledged program.

>
>  > 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 disagree, especially since it *reads* that way to me.

>
>  >
>  > 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.

Because it is a declaration.  Declarations do not typically get executed
more than once, unless it is *inside* a loop.

I'm not saying the functionality you want to create is not useful, or that
it would not help in many cases.  I'm not saying it should be either my
way or your way.  I'm saying, it *reads* like it could be both ways, and
therefore is confusing, and not worth adding to the language.  It will
lead to people expecting one case, even though it means the other, no
matter which way you choose it to mean.  We already have several people
split about evenly on what they expect.

-Steve