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/

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

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

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

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

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/

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.