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

[Timon Gehr]

On 08/25/2011 01:11 PM, Steven Schveighoffer wrote:
> On Wed, 24 Aug 2011 19:01:31 -0400, Timon Gehr <timon.gehr at gmx.ch> wrote:
>
>> On 08/25/2011 12:47 AM, Mafi wrote:
>>> Am 24.08.2011 21:04, schrieb Timon Gehr:
>>>> On 08/24/2011 08:04 PM, Andrej Mitrovic wrote:
>>>>> Here's some code that iterates through "parents" of some class object
>>>>> until it finds an object with no parent (where parent is null):
>>>>>
>>>>> import std.stdio;
>>>>>
>>>>> class Foo
>>>>> {
>>>>> Foo parent;
>>>>> int state;
>>>>>
>>>>> this (int state) { this.state = state; }
>>>>> }
>>>>>
>>>>> void main()
>>>>> {
>>>>> auto foo = new Foo(0);
>>>>> foo.parent = new Foo(1);
>>>>> foo.parent.parent = new Foo(2);
>>>>>
>>>>> while (true)
>>>>> {
>>>>> if (auto par = foo.parent)
>>>>> {
>>>>> writeln(par.state);
>>>>> foo = par;
>>>>> }
>>>>> else
>>>>> {
>>>>> break;
>>>>> }
>>>>> }
>>>>> }
>>>>>
>>>>> (syntax-highlighted: http://codepad.org/8yHRmICh)
>>>>>
>>>>> But I was hoping I could simplify this by doing:
>>>>>
>>>>> while (auto par = foo.parent)
>>>>> {
>>>>> writeln(par.state);
>>>>> foo = par;
>>>>> }
>>>>>
>>>>> However that doesn't work, I get back:
>>>>> expression expected, not 'auto'
>>>>>
>>>>> Is there a limitation on why this couldn't work or can this be added
>>>>> to the language?
>>>>
>>>> Afaics, this could be added just like it could be added for if. In fact
>>>> the compiler should be able to simply rewrite it to your first example.
>>>> I think it is worth an enhancement request, because there are
>>>> situations
>>>> where this would be useful, and implementation should be trivial, if
>>>> somebody has the time. (I also think it adds to the consistency of the
>>>> language, but others may disagree.)
>>>>
>>>>
>>>> (btw, i always use for(;;) instead of while(true), it is usually faster
>>>> in debug mode and faster to type :))
>>>
>>> I just have to say that it already works for 'if'. It's a great feature
>>> because in the body of the 'if' you know the value is non-null and
>>> outside, where there could be an segfault, the variable is not visible.
>>> I'm not really sure if it's good for 'while'.
>>> I'm unsure because there are two somewhat natural semantics for such a
>>> construct.
>>>
>>> //example
>>> //more to the nature of while
>>> while(auto obj = init) { work(obj); }
>>>
>>> //1 (your interpretation)
>>> typeof(init) obj;
>>> while(obj = init) { work(obj); }
>>>
>>> //2
>>> /*
>>> seems more natural for me because init runs only once (like any other
>>> init and like in 'for' or 'if')
>>> */
>>
>> for(;;){int x=init;} // init runs infinitely many times
>>
>>
>> if(auto a=init){} is really more trying to solve
>>
>> if(???){auto a=init;} // correct scoping but cannot refer to it in cond
>>
>> than
>>
>> {auto a=init; if(a){}} // correct scoping as long as there is no else
>>
>> That is why there is the language construct. That it has not been
>> adopted for while is because it is so much more useful for if, but I
>> personally think while could/should get the possibility as well.
>>
>>
>>
>>> auto obj = init;
>>> while(obj) { work(obj); }
>>>
>>> This could confuse many people, I think. What do you think?
>>>
>>
>> I think that by the same argument, you could say that the fact that
>> the body of a looping statement is executed multiple times could
>> confuse many people.
>>
>> 1 is more natural imho. (and 2 would be rather useless)
>
> I disagree -- I think the semantics are confusing.

while(condition) do_this;
while(auto d=condition) do_this_and_use_d;

I still think it is simple, but it is not a feature I miss often.

>
> I'd say just leave the auto x = y for if and for loops, where there is a
> clear "run once" section.
>
> Also, what do you do with a do while loop if the while contains this
> construct?
>

In do while it is useless because the scope ends after the condition.