www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Why no (auto foo = bar) in while loops?

reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
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?
Aug 24 2011
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
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 :))
Aug 24 2011
next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 8/24/11, Timon Gehr <timon.gehr gmx.ch> wrote:

 it is usually faster
 in debug mode


Huh.. How come?
Aug 24 2011
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 08/24/2011 09:21 PM, Andrej Mitrovic wrote:

 On 8/24/11, Timon Gehr<timon.gehr gmx.ch>  wrote:

 it is usually faster
 in debug mode


 Huh.. How come?


Well, not notably faster, but many compilers will emit something in the 
lines of

mov eax, 1
test eax
jnz beginning_of_loop

if no optimizer is run,

whereas most get

for(;;){}

as

jmp beginning_of_loop

even in debug mode.
Aug 24 2011
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday, August 24, 2011 21:29:23 Timon Gehr wrote:

 On 08/24/2011 09:21 PM, Andrej Mitrovic wrote:

 On 8/24/11, Timon Gehr<timon.gehr gmx.ch>  wrote:

 it is usually faster
 in debug mode


 
 Huh.. How come?


 
 Well, not notably faster, but many compilers will emit something in the
 lines of
 
 mov eax, 1
 test eax
 jnz beginning_of_loop
 
 if no optimizer is run,
 
 whereas most get
 
 for(;;){}
 
 as
 
 jmp beginning_of_loop
 
 even in debug mode.


Optimizations aside, I would always argue that while(true) should be used 
rather than for(;;). I find for(;;) to be ugly personally and would argue that 
while(true) better captures what you're actually doing. A loop with no 
condition at all is horrible IMHO. It seems completely inconsistent to me that 
the language would allow you to have a for loop without a condition.

Regardless of that, however, I would fully expect that if there is a difference 
in code between the two in debug mode (which there shouldn't be IMHO, but 
compilers don't always do what makes the most sense - especially in debug 
mode) that the difference would be drowned by the contents of the loop and 
wouldn't matter at all. But even if it did, I'd generally argue that coding in 
a certain way just because it was slightly faster in debug mode but had zero 
impact in release mode is not a good idea unless all of the considerations are 
equal. And I'd definitely argue that while(true) is better than for(;;) from an 
aesthetic point of view at minimum, so they definitely aren't equal.

In any case, that's my take on it.

- Jonathan M Davis
Aug 24 2011
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 08/24/2011 09:36 PM, Jonathan M Davis wrote:

 On Wednesday, August 24, 2011 21:29:23 Timon Gehr wrote:

 On 08/24/2011 09:21 PM, Andrej Mitrovic wrote:

 On 8/24/11, Timon Gehr<timon.gehr gmx.ch>   wrote:

 it is usually faster
 in debug mode


 Huh.. How come?


 Well, not notably faster, but many compilers will emit something in the
 lines of

 mov eax, 1
 test eax
 jnz beginning_of_loop

 if no optimizer is run,

 whereas most get

 for(;;){}

 as

 jmp beginning_of_loop

 even in debug mode.


 Optimizations aside, I would always argue that while(true) should be used
 rather than for(;;). I find for(;;) to be ugly personally and would argue that
 while(true) better captures what you're actually doing. A loop with no
 condition at all is horrible IMHO. It seems completely inconsistent to me that
 the language would allow you to have a for loop without a condition.

 Regardless of that, however, I would fully expect that if there is a difference
 in code between the two in debug mode (which there shouldn't be IMHO, but
 compilers don't always do what makes the most sense - especially in debug
 mode) that the difference would be drowned by the contents of the loop and
 wouldn't matter at all. But even if it did, I'd generally argue that coding in
 a certain way just because it was slightly faster in debug mode but had zero
 impact in release mode is not a good idea unless all of the considerations are
 equal. And I'd definitely argue that while(true) is better than for(;;) from an
 aesthetic point of view at minimum, so they definitely aren't equal.

 In any case, that's my take on it.

 - Jonathan M Davis


Well, it is consistent in that you can leave out the other parts in for 
too. (but those are statements, and you can almost everywhere write an 
empty statement, while there exist no empty expressions)

As to while(true) vs for(;;), in my point of view, it is the other way 
round, because how it is compiled in debug mode is really how the 
semantics of the language are: look at the condition, and if it is true, 
loop another time, if it is false, break. If you want an infinite loop, 
why bother having to write a condition to evaluate? Imho for(;;){} 
captures the meaning better than while(true){}. for(;;){} means, loop 
unconditionally (which proves insight in what it is actually doing), and 
while(true){} means 'loop until true is false', which is imo ugly for 
obvious reasons.

That is my way of thinking about aesthetics in programming.
Aug 24 2011
parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
Req'd: http://d.puremagic.com/issues/show_bug.cgi?id=6550
Aug 24 2011
prev sibling parent reply Mafi <mafi example.org> writes:
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')
*/
auto obj = init;
while(obj) { work(obj); }

This could confuse many people, I think. What do you think?

Mafi
Aug 24 2011
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
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)
Aug 24 2011
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 24 Aug 2011 19:01:31 -0400, Timon Gehr <timon.gehr 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.

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?

I just find the whole thing confusing.

-Steve
Aug 25 2011
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 08/25/2011 01:11 PM, Steven Schveighoffer wrote:

 On Wed, 24 Aug 2011 19:01:31 -0400, Timon Gehr <timon.gehr 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.
Aug 25 2011
prev sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday, August 25, 2011 07:11:31 Steven Schveighoffer wrote:

 On Wed, 24 Aug 2011 19:01:31 -0400, Timon Gehr <timon.gehr 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.
 
 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?
 
 I just find the whole thing confusing.


I don't see why it would be confusing. Because it's unclear whether it's set 
every time or whether it's a new variable every time? It's actually one of 
those things that I do periodically thinking that it works and then get 
frustrated when it doesn't, so I'd love to see it added.

- Jonathan M Davis
Aug 25 2011
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 25 Aug 2011 11:15:44 -0400, Jonathan M Davis <jmdavisProg gmx.com>  
wrote:


 On Thursday, August 25, 2011 07:11:31 Steven Schveighoffer wrote:

 On 08/25/2011 12:47 AM, Mafi wrote:







 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')
 */




 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?

 I just find the whole thing confusing.


 I don't see why it would be confusing. Because it's unclear whether it's  
 set
 every time or whether it's a new variable every time? It's actually one  
 of
 those things that I do periodically thinking that it works and then get
 frustrated when it doesn't, so I'd love to see it added.


See Mafi's response above.

What it boils down to is, I usually replace code like this:

auto x = condition;
if(x)
{
    // use x
}

with this:

if(auto x = condition)
{
    // use x.
}

so the logical mapping to while would map this:

auto x = condition;
while(x)
{
    // use x.
}

to this:

while(auto x = condition)
{
    // use x.
}

But it looks like every time through the loop x gets reassigned to  
condition.  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.

-Steve
Aug 25 2011
next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday, August 25, 2011 11:31:56 Steven Schveighoffer wrote:

 On Thu, 25 Aug 2011 11:15:44 -0400, Jonathan M Davis <jmdavisProg gmx.com>
 
 wrote:

 On Thursday, August 25, 2011 07:11:31 Steven Schveighoffer wrote:

 On 08/25/2011 12:47 AM, Mafi wrote:

 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')
 */




 
 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?
 
 I just find the whole thing confusing.


 
 I don't see why it would be confusing. Because it's unclear whether it's
 set
 every time or whether it's a new variable every time? It's actually one
 of
 those things that I do periodically thinking that it works and then get
 frustrated when it doesn't, so I'd love to see it added.


 
 See Mafi's response above.
 
 What it boils down to is, I usually replace code like this:
 
 auto x = condition;
 if(x)
 {
     // use x
 }
 
 with this:
 
 if(auto x = condition)
 {
     // use x.
 }
 
 so the logical mapping to while would map this:
 
 auto x = condition;
 while(x)
 {
     // use x.
 }
 
 to this:
 
 while(auto x = condition)
 {
     // use x.
 }
 
 But it looks like every time through the loop x gets reassigned to
 condition.  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.


Well, I'd definitely want it so that x is the value of the condition every 
time, and it surprises me that anyone would have thought that that would do 
anything else. The whole point of creating the variable in the if or while 
condition like that IMHO is so that you can save what the exact condition was 
for that run of the if statement or while loop without having to have to run 
the condition twice or have the variable exist outside the scope of the if-
statement or while-loop. If you wanted it to just be the value of the 
condition on the first iteration, then for does that already quite explicitly. 
But then again, assuming that for allows you to assign in the condition as 
well, then at least it's more explicit there, but I would have thought that 
the semantics of the while loop would have been quite clear.

- Jonathan M Davis
Aug 25 2011
prev sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 08/25/2011 05:31 PM, Steven Schveighoffer wrote:

 On Thu, 25 Aug 2011 11:15:44 -0400, Jonathan M Davis
 <jmdavisProg gmx.com> wrote:


 On Thursday, August 25, 2011 07:11:31 Steven Schveighoffer wrote:

 On 08/25/2011 12:47 AM, Mafi wrote:







 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')
 */




 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?

 I just find the whole thing confusing.


 I don't see why it would be confusing. Because it's unclear whether
 it's set
 every time or whether it's a new variable every time? It's actually
 one of
 those things that I do periodically thinking that it works and then get
 frustrated when it doesn't, so I'd love to see it added.


 See Mafi's response above.

 What it boils down to is, I usually replace code like this:

 auto x = condition;
 if(x)
 {
 // use x
 }

 with this:

 if(auto x = condition)
 {
 // use x.
 }

 so the logical mapping to while would map this:

 auto x = condition;
 while(x)
 {
 // use x.
 }

 to this:

 while(auto x = condition)
 {
 // use x.
 }

 But it looks like every time through the loop x gets reassigned to
 condition. 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.

 -Steve


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.

-Timon
Aug 25 2011
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 25 Aug 2011 12:21:19 -0400, Timon Gehr <timon.gehr 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.  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.

I have written loops like this:

bool found = false;
while(!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
}

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

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.

-Steve
Aug 25 2011
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 08/25/2011 10:51 PM, Steven Schveighoffer wrote:

 On Thu, 25 Aug 2011 12:21:19 -0400, Timon Gehr <timon.gehr 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.
Aug 25 2011
next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 25 Aug 2011 17:31:26 -0400, Timon Gehr <timon.gehr 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 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
Aug 25 2011
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 08/26/2011 12:38 AM, Steven Schveighoffer wrote:

 On Thu, 25 Aug 2011 17:31:26 -0400, Timon Gehr <timon.gehr 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 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. =)
Aug 25 2011
prev sibling parent reply Ali =?iso-8859-1?q?=C7ehreli?= <acehreli yahoo.com> writes:
On Thu, 25 Aug 2011 23:31:26 +0200, Timon Gehr wrote:


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


That's a very interesting way of looking at the question.

I bet that explains the other way around: there can't be a variable 
definition in the 'for' loop's condition clause, because 'while' doesn't 
allow it. :p

The compiler probably uses 'while's implementation. The 'for' loop 
probably becomes this:

{
    for_init;
    while (for_condition) {
        for_body;
        for_statement;
    }
}

So there is no discrepancy: the condition clauses cannot define a 
variable in either loop. :)

If 'while' gets this enhancement, 'for' could be written as the following:

for (int i = 0; auto c = condition(); ++i) {

    // Yes, we know that c doesn't evaluate to 'false', but
    // we can use c here when it evaluates to 'true'.
    // e.g. if it's a pointer:

    writeln(*c);
}

Ali
Aug 25 2011
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 08/26/2011 02:00 AM, Ali Çehreli wrote:

 On Thu, 25 Aug 2011 23:31:26 +0200, Timon Gehr wrote:


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


 That's a very interesting way of looking at the question.

 I bet that explains the other way around: there can't be a variable
 definition in the 'for' loop's condition clause, because 'while' doesn't
 allow it. :p

 The compiler probably uses 'while's implementation. The 'for' loop
 probably becomes this:

 {
      for_init;
      while (for_condition) {
          for_body;
          for_statement;
      }
 }

 So there is no discrepancy: the condition clauses cannot define a
 variable in either loop. :)


There is a little discrepancy because 'if' condition clauses can. ;)


 If 'while' gets this enhancement, 'for' could be written as the following:

 for (int i = 0; auto c = condition(); ++i) {

      // Yes, we know that c doesn't evaluate to 'false', but
      // we can use c here when it evaluates to 'true'.
      // e.g. if it's a pointer:

      writeln(*c);
 }


Only if it is specifically enabled. The compiler can only rewrite it to 
the while form if it can successfully parse it. But I think that indeed 
iff while is enhanced, for should be too.
Aug 25 2011