http://d.puremagic.com/issues/show_bug.cgi?id=603

           Summary: Undocumented behaviour: case and default create a scope
           Product: D
           Version: 0.175
          Platform: PC
               URL: http://www.digitalmars.com/d/statement.html#SwitchStatem
                    ent
        OS/Version: Windows
            Status: NEW
          Keywords: rejects-valid, spec
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: bugzilla@digitalmars.com
        ReportedBy: smjg@iname.com


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.


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=603


bugzilla@digitalmars.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID




------- Comment #1 from bugzilla@digitalmars.com  2006-12-15 03:10 -------
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.


-- 

d-bugmail@puremagic.com wrote:
> ------- Comment #1 from bugzilla@digitalmars.com  2006-12-15 03:10 -------
> 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.

d.puremagic.com seems to be down at the moment - so I wonder if this'll make it there....

Your marking this INVALID is nonsense.  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.

Stewart.

http://d.puremagic.com/issues/show_bug.cgi?id=603


smjg@iname.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|INVALID                     |




------- Comment #2 from smjg@iname.com  2006-12-16 20:36 -------
(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.


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=603





------- Comment #3 from baryluk@mpi.int.pl  2007-01-07 12:36 -------
We can say that switch do implicit goto, but spec say that useing goto for skiping initialisation is an error.


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=603





------- Comment #4 from smjg@iname.com  2007-01-07 15:06 -------
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.


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=603





------- Comment #5 from smjg@iname.com  2007-01-27 07:48 -------
(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.


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=603


kamm-removethis@incasoftware.de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kamm-
                   |                            |removethis@incasoftware.de




------- Comment #6 from kamm-removethis@incasoftware.de  2008-06-20 08:09 -------
*** Bug 2155 has been marked as a duplicate of this bug. ***


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=603





--- Comment #7 from Christian Kamm <kamm-removethis@incasoftware.de>  2009-07-07 11:50:12 PDT ---
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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=603


Sobirari Muhomori <maxmo@pochta.ru> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|rejects-valid               |diagnostic




--- Comment #8 from Sobirari Muhomori <maxmo@pochta.ru>  2009-07-08 01:45:16 PDT ---
Scoped case is a step towards switch redesign :) +1.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------