www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 3999] New: Enum equality to an int

reply d-bugmail puremagic.com writes:
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



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: -------
Mar 22 2010
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3999




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: -------
Mar 22 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3999




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: -------
Aug 31 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3999




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: -------
Sep 01 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3999




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: -------
Jun 13 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3999




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: -------
Aug 25 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3999


Trass3r <mrmocool gmx.de> changed:

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



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: -------
Jan 29 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3999




More or less, that is.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 29 2012
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3999




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: -------
May 28 2012