[Issue 3999] Enum equality to an int

2015-06-09 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=3999

Andrei Alexandrescu and...@erdani.com changed:

   What|Removed |Added

Version|future  |D2

--


[Issue 3999] Enum equality to an int

2012-05-28 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3999



--- Comment #9 from bearophile_h...@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: ---


[Issue 3999] Enum equality to an int

2012-01-29 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3999


Trass3r mrmoc...@gmx.de changed:

   What|Removed |Added

 CC||mrmoc...@gmx.de


--- Comment #7 from Trass3r mrmoc...@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: ---


[Issue 3999] Enum equality to an int

2012-01-29 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3999



--- Comment #8 from Trass3r mrmoc...@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: ---


[Issue 3999] Enum equality to an int

2011-08-25 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3999



--- Comment #5 from bearophile_h...@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() != -0x1'


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: ---


[Issue 3999] Enum equality to an int

2010-09-01 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3999



--- Comment #3 from bearophile_h...@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: ---


[Issue 3999] Enum equality to an int

2010-08-31 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3999



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

http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.Darticle_id=116546

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


[Issue 3999] Enum equality to an int

2010-03-22 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3999



--- Comment #1 from bearophile_h...@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: ---