I've noticed an interesting behaviour: the code between two consecutive case or default labels creates a scope. ---------- import std.stdio; void main() { int qwert; switch (qwert) { case 42: int yuiop; int asdfg; default: int hjkl = 98; writefln(yuiop); writefln(asdfg); writefln(hjkl); } } ---------- D:\My Documents\Programming\D\Tests\label_scope_2.d(12): Error: undefined identifier yuiop D:\My Documents\Programming\D\Tests\label_scope_2.d(13): Error: undefined identifier asdfg ---------- While this is intuitively sensible (it enables cases to define their own variables independently of each other), it doesn't follow from the logical code structure (in which all cases are at one level immediately below the SwitchStatement) or from anything on the relevant page of the spec.
What happens is the { } after the switch creates a new scope. The case and default statements are just labels. I believe the grammar implies this behavior, and no changes are necessary.
(Originally posted to digitalmars.D.bugs) A bug is a bug, whether it's the spec or the compiler that's doing what you intended. If the case and default statements weren't themselves creating scopes, then there would be no "undefined identifier" errors. If the errors aren't coming up when you try my testcase, then DMD has an OS-version-dependent bug.
We can say that switch do implicit goto, but spec say that useing goto for skiping initialisation is an error.
See issue 602. Moreover, it isn't clear whether a goto should be allowed to skip a declaration with no explicit initializer. While you could question the validity of the code on this basis, you can't sensibly claim this as the reason for the particular error message reported.
(In reply to comment #3) > We can say that switch do implicit goto, but spec say that useing goto for > skiping initialisation is an error. With that premise, the code would be invalid even if the default section doesn't touch yuiop or asdfg. It's still skipping initialisation even if what hasn't been initialised is never used. The variables are nonetheless in scope, if you believe the spec rather than the compiler.
*** Bug 2155 has been marked as a duplicate of this bug. ***
The fact that default and case statements create a new scope is evident in the frontend code: statements = new Statements(); while (token.value != TOKcase && token.value != TOKdefault && token.value != TOKrcurly) { statements->push(parseStatement(PSsemi | PScurlyscope)); } s = new CompoundStatement(loc, statements); s = new ScopeStatement(loc, s); With this in mind, it would make sense to add this to the section on switch statements: Case and default statements create a new scope that contains all statements up until the next case or default statement with the same parent, or the end of the enclosing scope. Example: switch(i) { case 1: ... case 2: if (i) { case 3: ... case 4: ... } case 5: } is equivalent to switch(i) { case 1: { ... } case 2: { if (i) { case 3: { ... } case 4: { ... } } } case 5: } I'm not marking this as 'patch' because I'm not happy with 'with the same parent'. Suggestions? Also, can someone suggest a grammar change that would explain this behavior? Replacing case ExpressionList : Statement with case ExpressionList : ScopeStatement isn't right as ScopeStatement is either BlockStatement or NonEmptyStatement. I think we need a new ScopeCaseStatement here.
Scoped case is a step towards switch redesign :) +1.
http://www.dsource.org/projects/phobos/changeset/2129
Ahh, I'm confused. Wrong fix.
http://www.dsource.org/projects/phobos/changeset/2130 This should do it.