www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 1560] New: Skip switch warning for complete enum set

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1560

           Summary: Skip switch warning for complete enum set
           Product: D
           Version: 1.021
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: bugzilla digitalmars.com
        ReportedBy: david acz.org


Consider the following:

void main()
{
    enum T { RED, GREEN, BLUE }
    T t;

    switch (t)
    {
        case T.RED: break;
        case T.GREEN: break;
        case T.BLUE: break;
    }
}

DMD gives two warnings:

warning - foo.d(8): Error: switch statement has no default
warning - foo.d(8): Error: statement is not reachable

A default is not needed as all enum values are handled.  Omitting the default
and warning here gives us the same functionality as g++:

warning: enumeration value `xxx' not handled in switch


--
Oct 09 2007
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1560


smjg iname.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |smjg iname.com
           Keywords|                            |diagnostic





DMD 1.022 (Windows) reports both warnings at line 6.

The more significant bug here is that the second warning is complete nonsense,
not to mention that both messages suffer from issue 952.

There are a few issues at work here:
- as you say, all the enum values have been considered
- the second warning is complete nonsense

However, you could debate whether it should still issue the warning
nonetheless.  There are various reasons that an enum variable might contain a
value that isn't one of the named values, for example:
- it's a set of bit flags
- the enum's value list is incomplete (likely when interfacing OS or other
foreign APIs)
- some system of enums derived from enums is used to group them into categories
- malformed data read from a file

But should we assume that the programmer knows what he/she is doing in such
cases?


--
Oct 10 2007
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1560






Sorry about the confusion on the line numbers.  I was running it as a shell
script, thus it had two extra lines above the code shown.

I hadn't considered an enum instance containing an invalid value, though to my
knowledge you have to intentionally do that with a cast.

Ignoring the issue of default, it would be still helpful to know at compile
time if all enum cases are handled, but perhaps not in all cases.  How could
this be checked cleanly?

A similar case is when maintaining a parallel array:

char[][] name = [T.RED : "red", T.BLUE : "blue"];

How can we determine that GREEN is missing at compile time?


--
Oct 10 2007
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1560








 I hadn't considered an enum instance containing an invalid value, though to my
 knowledge you have to intentionally do that with a cast.


My point is that it isn't necessarily invalid.  And you don't need a cast.  You
can combine enum values with arithmetic or bitwise operations, for example. 
Hence my mention of bit flags.


 Ignoring the issue of default, it would be still helpful to know at compile
 time if all enum cases are handled, but perhaps not in all cases.  How could
 this be checked cleanly?


I don't think there's any way we can be sure of considering all cases.  But a
possibility is to have a notation such as "switch enum (t)", such that it would
be a compile-time error not to consider all named values of the enum (whether
individually or with a default).  This would be a form of syntactic salt
similar to the override attribute.


 A similar case is when maintaining a parallel array:
 
 char[][] name = [T.RED : "red", T.BLUE : "blue"];
 
 How can we determine that GREEN is missing at compile time?


It used to be specified that an array must be initialised completely or not at
all.  See issue 508.  But this was never implemented.  Still, to work in this
instance, either the array's length would have to be explicitly given as T.max
+ 1, or it would miss a missing index at the end.


--
Oct 10 2007
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1560


Don <clugdbug yahoo.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |clugdbug yahoo.com.au
         Resolution|                            |FIXED



Fixed in D2 with 'final switch'.
It's WONTFIX for D1.

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