Comment #0 by bearophile_hugs — 2010-03-22T07:04:27Z
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>
Comment #1 by bearophile_hugs — 2010-03-22T13:42:16Z
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.
Comment #2 by bearophile_hugs — 2010-08-31T18:38:56Z
Comment #3 by bearophile_hugs — 2010-09-01T15:13:03Z
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.
Comment #4 by bearophile_hugs — 2011-06-13T17:02:20Z
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 ...
Comment #5 by bearophile_hugs — 2011-08-25T02:19:30Z
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.
Comment #6 by bearophile_hugs — 2011-08-27T17:48:05Z
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.
Comment #8 by hoganmeier — 2012-01-29T14:30:28Z
More or less, that is.
Comment #9 by bearophile_hugs — 2012-05-28T13:58:33Z
See also Issue 8157 , that essentially is a subset of this issue.
Comment #10 by robert.schadek — 2024-12-13T17:51:57Z