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.

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

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

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

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

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

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.

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

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

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