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

           Summary: Enum equality to an int
           Product: D
           Version: future
          Platform: x86
        OS/Version: Windows
            Status: NEW
          Keywords: accepts-invalid
          Severity: enhancement
          Priority: P2
         Component: DMD
        AssignedTo: nobody@puremagic.com
        ReportedBy: bearophile_hugs@eml.cc


--- Comment #0 from bearophile_hugs@eml.cc 2010-03-22 07:04:27 PDT ---
This D2 code compiles and doesn't assert at runtime (tested with dmd 2.042, that's absent in the versions list in this page):


enum Foo { V1 = 10 }
void main() {
    assert(Foo.V1 == 10);
}


But enums are not integers, and a language has to discourage hard-coded comparisons between enum instances and number literals, so I think it's better to require a cast to compare an enum to an int:

assert(cast(int)(Foo.V1) == 10); // OK


Note: in C++0x Foo::V1 == 10 is a compile error, enum and int can't be compared:


enum class Foo { V1 = 10 };
int main() {
    int b = Foo::V1 == 10;
}


test.cpp: In function 'int main()':
test.cpp:3: error: no match for 'operator==' in '(Foo)10 == 10'
test.cpp:3: note: candidates are: operator==(int, int) <built-in>

-- 
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=3999



--- Comment #1 from bearophile_hugs@eml.cc 2010-03-22 13:42:16 PDT ---
As div0 reminds me, the D docs state:

A named enum member can be implicitly cast to its EnumBaseType,

But I am not sure this is the best design.

-- 
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=3999



--- Comment #2 from bearophile_hugs@eml.cc 2010-08-31 18:38:56 PDT ---
See a discussion here:

http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=116546

-- 
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=3999



--- Comment #3 from bearophile_hugs@eml.cc 2010-09-01 15:13:03 PDT ---
This simple example shows a possible way to implement this (currently with dmd 2.048 this program runs firing no asserts):


enum V1 = 10;
enum { V2 = 20 }
enum : int { V2b = 25 }
enum { V3a = 20, V3b = 30 }
enum Foo { V4 }
enum Color : int { red, green, blue }
void main() {
    assert(V1 == 10);         // OK
    assert(V2 == 20);         // OK
    assert(V2b == 25);        // OK
    assert(V3b == 30);        // OK
    assert(Foo.V4 == 0);      // ERROR, type mismatch
    assert(Color.green == 1); // ERROR, type mismatch
}


So this bug 3999 is meant to restrict only the last two examples, where the EnumTag is present in the enum definition. All other enum usages are unchanged by this proposal.

See also the ideas behind the design of the C++0x "enum class". One of the purposes of "enum class" is to remove implicit conversions to int: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1719.pdf

If bug bug 3999 gets accepted, then bug 4261 too may be considered, because then enums aren't "values" but symbols, and the most natural way to print them on default becomes their name.

-- 
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=3999



--- Comment #4 from bearophile_hugs@eml.cc 2011-06-13 17:02:20 PDT ---
This is related. This code gives no compilation errors with DMD 2.053, but it's a reduced version of code that has caused me some troubles:


enum Foo { A, B }
void main() {
    char c = Foo.B;
}


Here I'd like an error like "cannot implicitly convert expression ... of type ... to ...

-- 
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=3999



--- Comment #5 from bearophile_hugs@eml.cc 2011-08-25 02:19:30 PDT ---
One example of bug caused by the semantic sloppiness of D enums. This is reduced code of a small game. The main contains a while that loops until the game is finished.

The original version of this program was simpler, and instead of using the GameState enum, it just used 0, 1 and -1 constants in the code.

So the original version of isFinished tests if winner() != -1. Later I have used the enum GameState, that the winner function now returns. Bug I have forgotten to update the isFinished() function too. The D language doesn't catch that simple bug:


struct GameBoard {
    // ...
    enum GameState { inProgress, draw, humanWins, computerWins }

    GameState winner() {
        // this function used to return -1, 1, 0 values
        // ...
    }

    bool isFinished() {
        return winner() != -1; // not updated function!
        //return winner() != GameState.inProgress; // correct code!
    }
}
void main() {
    // ...
    Board game;

    while (!game.isFinished()) {
        // ...
    }
    // ...
}


In a bigger program it becomes hard to catch a similar bug (this bug was not found also because of another waeak typing characteristic of D language: inside isFinished it allowes you to compare an unsigned size_t value with -1, despite -1 is statically visibly outside the range of possible unsigned values).

If I write similar code in C++11, it catches that bug:


enum class GameState {
    inProgress,
    draw,
    humanWins,
    computerWins
};
GameState winner() {
    return GameState::draw;
}
bool isFinished() {
    return winner() != -1; // line 11, error
}
int main() {}


G++ 4.6.0 outputs:

test.cpp: In function 'bool isFinished()':
test.cpp:11:25: error: no match for 'operator!=' in 'winner() != -0x000000001'


In D "final switches" where introduces right to avoid this class of bugs (if you add an item to an enumeration, and you forget to add a case in a final switch, the final switch will generate an error. This forces you at compile-time to consider all cases, as pattern matching does in some functional languages. Accepting enum conversions to ints causes similar bugs).

Please make named D enums strongly typed. Weak typing is better left to old versions of the C language.

-- 
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=3999


Trass3r <mrmocool@gmx.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mrmocool@gmx.de


--- Comment #7 from Trass3r <mrmocool@gmx.de> 2012-01-29 23:29:52 CET ---
votes++
Implicit conversion to the basetype only leads to bugs.
People will still be free to use anonymous enums + an alias or maybe even
library typedef to achieve the current functionality.

-- 
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=3999



--- Comment #8 from Trass3r <mrmocool@gmx.de> 2012-01-29 23:30:28 CET ---
More or less, that is.

-- 
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=3999



--- Comment #9 from bearophile_hugs@eml.cc 2012-05-28 13:58:33 PDT ---
See also Issue 8157 , that essentially is a subset of this issue.

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