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


-- 

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


smjg@iname.com changed:

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




------- Comment #1 from smjg@iname.com  2007-10-10 08:16 -------
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?


-- 

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





------- Comment #2 from david@acz.org  2007-10-10 14:53 -------
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?


-- 

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





------- Comment #3 from smjg@iname.com  2007-10-10 18:32 -------
(In reply to comment #2)
> 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.


-- 

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


--- Comment #4 from Don <clugdbug@yahoo.com.au> 2011-12-22 01:10:42 PST ---
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: -------