www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - effect of a label on following block

reply "Nick Voronin" <elfy.nv gmail.com> writes:
Hello.

Consider this code

void main()
{
l:
   {
     int v;
   }
   v = 5; // ok, v is defined
}

As I understand from D's grammar this behaviour is not a bug as

LabeledStatement:
     Identifier : NoScopeStatement

and NoScopeStatement in turn takes BlockStatement without creating new  
scope.

It looks very unnatural for me though. Especially when label goes before  
ThenStatement

if(1)
l1:{
   int v;
}
v = 5;

it works as above, yet label after 'while'

while(1)
l1:{
   int v;
}
v = 5; // error, v is undefined

has no such effect, even if ThenStatement is just another ScopeStatement.  
I don't understand this difference. Any rationale behind this?

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/
Nov 15 2010
parent reply Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
My gut feeling is that the if statement's behavior is wrong and the 
while statement's is correct, but it could go either way.

No need for a rationale for what can be adequately explained as a 
compiler bug (this is a downside of dmd - it trains you to think like 
this) It is curious, though, as it looks like both bodies get parsed the 
same way. Not sure what's going on.

Please to report to bugzilla
Nov 15 2010
next sibling parent reply Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
poking around a little more and I really don't know what's going on.

fun piece of trivia though: while loops get rewritten to for loops, so

for(;;) l1 {
    int v;
}
v = 4;

exhibits the same behavior as the while loop.

do loops seem to do the same thing as the if statement

On 11/15/2010 10:34 AM, Ellery Newcomer wrote:

 My gut feeling is that the if statement's behavior is wrong and the
 while statement's is correct, but it could go either way.

 No need for a rationale for what can be adequately explained as a
 compiler bug (this is a downside of dmd - it trains you to think like
 this) It is curious, though, as it looks like both bodies get parsed the
 same way. Not sure what's going on.

 Please to report to bugzilla
Nov 15 2010
parent div0 <div0 sourceforge.net> writes:
On 15/11/2010 16:45, Ellery Newcomer wrote:

 poking around a little more and I really don't know what's going on.

 fun piece of trivia though: while loops get rewritten to for loops, so

 for(;;) l1 {
 int v;
 }
 v = 4;

 exhibits the same behavior as the while loop.

 do loops seem to do the same thing as the if statement


Eugh, that's fugly.

Labels shouldn't be allowed between keyword statements and their blocks, 
it makes no sense in any circumstance.

-- 
My enormous talent is exceeded only by my outrageous laziness.
http://www.ssTk.co.uk
Nov 15 2010
prev sibling next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Ellery Newcomer:


 No need for a rationale for what can be adequately explained as a 
 compiler bug (this is a downside of dmd - it trains you to think like 
 this)


Or: Any sufficiently incomprehensible behaviour is indistinguishable from a DMD
compiler bug :-)

Bye,
bearophile
Nov 15 2010
prev sibling parent reply "Nick Voronin" <elfy.nv gmail.com> writes:
On Mon, 15 Nov 2010 19:34:46 +0300, Ellery Newcomer  
<ellery-newcomer utulsa.edu> wrote:


 My gut feeling is that the if statement's behavior is wrong and the  
 while statement's is correct, but it could go either way.


I agree, I think case with 'when' works as specs say.


 No need for a rationale for what can be adequately explained as a  
 compiler bug


There is still correct but unexpected behaviour. I found this on bugtracker
http://d.puremagic.com/issues/show_bug.cgi?id=199
The rationale was "I don't want to change this because it could break  
existing code,
and there doesn't seem to be a compelling reason to do so." Well. :(


 Please to report to bugzilla


I'll report about if/while inconsistency.

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/
Nov 16 2010
parent Stewart Gordon <smjg_1998 yahoo.com> writes:
On 16/11/2010 15:11, Nick Voronin wrote:
<snip>

 There is still correct but unexpected behaviour. I found this on bugtracker
 http://d.puremagic.com/issues/show_bug.cgi?id=199
 The rationale was "I don't want to change this because it could break
 existing code,
 and there doesn't seem to be a compelling reason to do so." Well. :(


<snip>

True, but that does nothing to explain why it was defined this way in 
the first place.

Stewart.
Nov 16 2010