Bill Baxter Wrote:
>     typeof(condition()) x;
>     while(x = condition()) {
>         // do stuff
>     }
> }

Which is frighteningly different semantically, while being almost identical syntactically to:

while(x == condition()) {

Which is probably why Walter didn't want it to work.  It concerns me a little that if(x = 3) works.

Honestly, D is syntactically abstracted away enough that while(something something) wouldn't have to compile down to evaluating it repeatedly.

On Tue, 24 Apr 2007 20:18:24 +0300, Max Samukha <samukha@voliacable.com> wrote:

>On Wed, 25 Apr 2007 01:53:56 +0900, Bill Baxter <dnewsgroup@billbaxter.com> wrote:
>
>>BCS wrote:
>>> Bill Baxter wrote:
>>>> BCS wrote:
>>>>
>>>>> Bill Baxter wrote:
>>>>
>>>>
>>>>> how about take a trick from "if"
>>>>>
>>>>> with(auto name = new someGUIWidget(myParent))
>>>>> {
>>>>>    shown = true;
>>>>>    focusable = false;
>>>>>    some_global_function(name);
>>>>> }
>>>>
>>>>
>>>> Yeh, I was actually just thinking that myself, and was disappointed to find out it doesn't work.  :-(
>>>>
>>>> Looking at the spec it seems that's special to 'if'.   It could be useful for switch(), with() and synchronized(), but it seems it hasn't been added.
>>>>
>>>> --bb
>>> 
>>> Ohhh. That would be nice in switch ... and while...
>>
>>I was thinking 'while' would have issues, because the condition is
>>evaluated multiple times.  So I left it off the list.  Maybe it's not a
>>problem though.  Just make it equiv to
>>{
>>    typeof(condition()) x;
>>    while(x = condition()) {
>>        // do stuff
>>    }
>>}
>>
>>--bb
>
>This would be inconsistent with if(), which declares the variable to be local to if's scope. BTW, it'd be nice to have the variable declared outside the if block as you proposed for 'with'. I remember a case or two when I wanted that.
>
>
> 

BTW, there is a bug

void main(char[][] f)
{
    int x = 1;

    if (auto x = 2)
    {
        writefln(x);
    }

    writefln(x);
}

x in if() shadows the outer x and it shouldn't according to the specs

Max Samukha wrote:
> On Wed, 25 Apr 2007 01:53:56 +0900, Bill Baxter
> <dnewsgroup@billbaxter.com> wrote:
> 
>> BCS wrote:
>>> Bill Baxter wrote:
>>>> BCS wrote:
>>>>
>>>>> Bill Baxter wrote:
>>>>
>>>>> how about take a trick from "if"
>>>>>
>>>>> with(auto name = new someGUIWidget(myParent))
>>>>> {
>>>>>    shown = true;
>>>>>    focusable = false;
>>>>>    some_global_function(name);
>>>>> }
>>>>
>>>> Yeh, I was actually just thinking that myself, and was disappointed to find out it doesn't work.  :-(
>>>>
>>>> Looking at the spec it seems that's special to 'if'.   It could be useful for switch(), with() and synchronized(), but it seems it hasn't been added.
>>>>
>>>> --bb
>>> Ohhh. That would be nice in switch ... and while...
>> I was thinking 'while' would have issues, because the condition is evaluated multiple times.  So I left it off the list.  Maybe it's not a problem though.  Just make it equiv to
>> {
>>    typeof(condition()) x;
>>    while(x = condition()) {
>>        // do stuff
>>    }
>> }
>>
>> --bb
> 
> This would be inconsistent with if(), which declares the variable to
> be local to if's scope. BTW, it'd be nice to have the variable
> declared outside the if block as you proposed for 'with'. I remember a
> case or two when I wanted that.

No that's not what I meant.  Note the extra block scope _outside_ the while.  That would be silently introduced by the transformation.  The scope added is a scope that you have no way of interacting with or introducing code into, so effectively it *is* limiting the var scope to the scope of the while().  Of course there are no "scopes" anyway after everything gets compiled down to ASM, so its all just pleasant fictions to help us poor humans understand what's going on.

--bb

Max Samukha wrote:
> On Tue, 24 Apr 2007 20:18:24 +0300, Max Samukha
> <samukha@voliacable.com> wrote:
> 
>> On Wed, 25 Apr 2007 01:53:56 +0900, Bill Baxter
>> <dnewsgroup@billbaxter.com> wrote:
>>
>>> BCS wrote:
>>>> Bill Baxter wrote:
>>>>> BCS wrote:
>>>>>
>>>>>> Bill Baxter wrote:
>>>>>
>>>>>> how about take a trick from "if"
>>>>>>
>>>>>> with(auto name = new someGUIWidget(myParent))
>>>>>> {
>>>>>>    shown = true;
>>>>>>    focusable = false;
>>>>>>    some_global_function(name);
>>>>>> }
>>>>>
>>>>> Yeh, I was actually just thinking that myself, and was disappointed to find out it doesn't work.  :-(
>>>>>
>>>>> Looking at the spec it seems that's special to 'if'.   It could be useful for switch(), with() and synchronized(), but it seems it hasn't been added.
>>>>>
>>>>> --bb
>>>> Ohhh. That would be nice in switch ... and while...
>>> I was thinking 'while' would have issues, because the condition is evaluated multiple times.  So I left it off the list.  Maybe it's not a problem though.  Just make it equiv to
>>> {
>>>    typeof(condition()) x;
>>>    while(x = condition()) {
>>>        // do stuff
>>>    }
>>> }
>>>
>>> --bb
>> This would be inconsistent with if(), which declares the variable to
>> be local to if's scope. BTW, it'd be nice to have the variable
>> declared outside the if block as you proposed for 'with'. I remember a
>> case or two when I wanted that.
>>
>>
>>
> 
> BTW, there is a bug
> 
> void main(char[][] f)
> {
>     int x = 1;
> 
>     if (auto x = 2)
>     {
>         writefln(x);
>     }
> 
>     writefln(x);
> }
> 
> x in if() shadows the outer x and it shouldn't according to the specs

You mean it should be an error according to the specs, right?
--bb

Dan wrote:
> Bill Baxter Wrote:
> 
>>    typeof(condition()) x;
>>    while(x = condition()) {
>>        // do stuff
>>    }
>>}
> 
> 
> Which is frighteningly different semantically, while being almost identical syntactically to:
> 
> while(x == condition()) {
> 
> Which is probably why Walter didn't want it to work.  It concerns me a little that if(x = 3) works.  
> 
> Honestly, D is syntactically abstracted away enough that while(something something) wouldn't have to compile down to evaluating it repeatedly.
> 
> 

if(x = 3) doesn't compile. For the If case the syntax requiters that the type specifier be used:

if(auto x = 3) // works
if(x == 3) // works
if(x = 3) // fails

OTOH with 'wile' the third case is totally legitimate

char x;
while(x = getc()) // scan for null and use non null in loop;

actually the proposed addition would make that error less likely, in fact the direct assignment could be banned in a while statement.

char x;

while(auto c = getc())
{
	x=c; // if last c needed;
	break;
}

On Wed, 25 Apr 2007 02:35:02 +0900, Bill Baxter <dnewsgroup@billbaxter.com> wrote:

>Max Samukha wrote:
>> On Wed, 25 Apr 2007 01:53:56 +0900, Bill Baxter <dnewsgroup@billbaxter.com> wrote:
>> 
>>> BCS wrote:
>>>> Bill Baxter wrote:
>>>>> BCS wrote:
>>>>>
>>>>>> Bill Baxter wrote:
>>>>>
>>>>>> how about take a trick from "if"
>>>>>>
>>>>>> with(auto name = new someGUIWidget(myParent))
>>>>>> {
>>>>>>    shown = true;
>>>>>>    focusable = false;
>>>>>>    some_global_function(name);
>>>>>> }
>>>>>
>>>>> Yeh, I was actually just thinking that myself, and was disappointed to find out it doesn't work.  :-(
>>>>>
>>>>> Looking at the spec it seems that's special to 'if'.   It could be useful for switch(), with() and synchronized(), but it seems it hasn't been added.
>>>>>
>>>>> --bb
>>>> Ohhh. That would be nice in switch ... and while...
>>> I was thinking 'while' would have issues, because the condition is
>>> evaluated multiple times.  So I left it off the list.  Maybe it's not a
>>> problem though.  Just make it equiv to
>>> {
>>>    typeof(condition()) x;
>>>    while(x = condition()) {
>>>        // do stuff
>>>    }
>>> }
>>>
>>> --bb
>> 
>> This would be inconsistent with if(), which declares the variable to be local to if's scope. BTW, it'd be nice to have the variable declared outside the if block as you proposed for 'with'. I remember a case or two when I wanted that.
>
>No that's not what I meant.  Note the extra block scope _outside_ the while.  That would be silently introduced by the transformation.  The scope added is a scope that you have no way of interacting with or introducing code into, so effectively it *is* limiting the var scope to the scope of the while().  Of course there are no "scopes" anyway after everything gets compiled down to ASM, so its all just pleasant fictions to help us poor humans understand what's going on.
>
>--bb

 I understand now. But in your second proposal you want the object to
be accessible outside the 'with' block, so would it better to declare
the variable outside the scope in the first place?

with(auto name = new someGUIWidget(myParent))
{
  shown = true;
  focusable = false;
  some_global_function(name);
}

name.shown = false;

On Wed, 25 Apr 2007 02:38:26 +0900, Bill Baxter <dnewsgroup@billbaxter.com> wrote:

>Max Samukha wrote:
>> On Tue, 24 Apr 2007 20:18:24 +0300, Max Samukha <samukha@voliacable.com> wrote:
>> 
>>> On Wed, 25 Apr 2007 01:53:56 +0900, Bill Baxter <dnewsgroup@billbaxter.com> wrote:
>>>
>>>> BCS wrote:
>>>>> Bill Baxter wrote:
>>>>>> BCS wrote:
>>>>>>
>>>>>>> Bill Baxter wrote:
>>>>>>
>>>>>>> how about take a trick from "if"
>>>>>>>
>>>>>>> with(auto name = new someGUIWidget(myParent))
>>>>>>> {
>>>>>>>    shown = true;
>>>>>>>    focusable = false;
>>>>>>>    some_global_function(name);
>>>>>>> }
>>>>>>
>>>>>> Yeh, I was actually just thinking that myself, and was disappointed to find out it doesn't work.  :-(
>>>>>>
>>>>>> Looking at the spec it seems that's special to 'if'.   It could be useful for switch(), with() and synchronized(), but it seems it hasn't been added.
>>>>>>
>>>>>> --bb
>>>>> Ohhh. That would be nice in switch ... and while...
>>>> I was thinking 'while' would have issues, because the condition is
>>>> evaluated multiple times.  So I left it off the list.  Maybe it's not a
>>>> problem though.  Just make it equiv to
>>>> {
>>>>    typeof(condition()) x;
>>>>    while(x = condition()) {
>>>>        // do stuff
>>>>    }
>>>> }
>>>>
>>>> --bb
>>> This would be inconsistent with if(), which declares the variable to be local to if's scope. BTW, it'd be nice to have the variable declared outside the if block as you proposed for 'with'. I remember a case or two when I wanted that.
>>>
>>>
>>>
>> 
>> BTW, there is a bug
>> 
>> void main(char[][] f)
>> {
>>     int x = 1;
>> 
>>     if (auto x = 2)
>>     {
>>         writefln(x);
>>     }
>> 
>>     writefln(x);
>> }
>> 
>> x in if() shadows the outer x and it shouldn't according to the specs
>
>You mean it should be an error according to the specs, right? --bb

Yes