NoScopeStatement violates C compatibility principal.

[monarch_dodra]

I have created before two threads about the weird semantics of 
labeled block statements. In a word: putting a label before a 
block means that block does not create a scope, and the variables 
created inside that scope will "leak" to the outside of said 
scope. I've found this to be problematic on several points:

1. No use case for this
2. You can accidentally break code by placing a label before a 
block (but without meaning to label the actual block)
3. Deviates from C.

What kind of bothers me most is the combination 1 & 3: Why??? 
I've complained about this before, and the answer was: "According 
to spec", but to the question "why are the specs like this", I 
have yet to get an answer.

----------------
The reason I'm bringing this up (again), is that it bit me in the 
ass very recently. According to TDPL:

"If a numeric expression compiles in the C language and also 
compiles in D, its
type will be the same in both languages (note that not all C 
expressions must be
accepted by D)."

Followed by

"Rule 1 makes things just a tad more complicated than they would 
otherwise be, but D overlaps enough with C and C++ to inspire 
people to simply copy and paste entire functions into D programs. 
Now it’s all right if D occasionally refuses to compile certain 
constructs for safety or portability reasons; but if it compiled 
that 2000-line encryption package and ran it with different 
results, life would definitely not be good for the hapless 
victim."

So basically, this is saying "If your C code compiles in D, 
you'll get the same result. I guarantee it :)"

Here's a (reduced) C program:

----
int i = 3;

void main()
{
   {
     int some_condition = 1;
     if ( some_condition )
       goto block_end;

     /* dummy code */
   } block_end:

   {
     int i = 7;
     printf("%i", i);
   }

   printf("%i", i);
}
----
C prints: "70"
D prints: "77"

Oops!

I realize 99% of people don't use goto or labels too much, but 
this doesn't mean it shouldn't be addressed. For me, D has been 
about being a "smooth experience", and this makes so little sense 
to me it infuriates me.

I don't see how this could help anyone, but I do see how it can 
create bugs, and these kinds of cases are what D strives to 
avoid. "Fixing" would probably break nothing.

-------------------
I'd like to make a push to get the specs changed in regards to 
this. I'd like to get others' opinion on the matter, in 
particular, if anybody can think of a rationale for the current 
behavior. And if there is no rationale, how much support there is 
for changing it. (in which case I'll file the corresponding ER).