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

Timon Gehr timon.gehr at gmx.ch
Thu Aug 25 16:43:27 PDT 2011


On 08/26/2011 12:38 AM, Steven Schveighoffer wrote:
> 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 :)

As an analogy, you said: "We have loops so that we can hide gotos". I 
said: "We have loops so that we can execute code sequences multiple 
times". :)

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

Yes, but then I don't get type inference, which is not very D-like.

>>
>>
>> >
>> > 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 suggest you reconsider.

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

while(condition) statement;
      ~~~~~~~~~~~~~~~~~~~~~~~
               ^- inside loop

How can you say the condition is not part of the loop? It is looped too.
>
> 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

Well, I don't get it. If I ever write a D compiler, this feature will be 
supported. =)


More information about the Digitalmars-d-learn mailing list