Nick Sabalausky Wrote: > "yigal chripun" <yigal...@gmail.com> wrote in message > news:hobg4b$12e...@digitalmars.com... > > > > This also interacts with the crude hack of "this enum is actually a > > constant". > > if you remove the implicit casts than how would you be able to do: > > void foo(int p); > > enum { bar = 4 }; // don't remember the exact syntax here > > foo(bar); // compile-error?! > > > > AIUI, That style enum is already considered different by the compiler > anyway. Specifically, it's doesn't create any new type, whereas the other > type of enum creates a new semi-weak type. I don't think it would be too big > of a step to go one step further and change "this kind of enum creates a new > semi-weak type" to "this kind of enum creates a new strong type". But yea, I > absolutely agree that calling a manifest constant an "enum" is absurd. It > still bugs the hell out of me even today, but I've largely shut up about it > since Walter hasn't wanted to change it even though he seems to be the only > one who doesn't feel it's a bad idea (and it's not like it causes practical > problems when actually using the language...although I'm sure it must be a > big WTF for new and prospective D users). > > > > I feel that enum needs to be re-designed. I think that C style "enums are > > numbers" are *bad*, *wrong* designs that expose internal implementation > > and the only valid design is that of Java 5. > > > > e.g. > > enum Color {blue, green} > > Color c = Color.blue; > > c++; // WTF? should NOT compile > > > > A C style enum with values assigned is *not* an enumeration but rather a > > set of meaningful integral values and should be represented as such. > > > > This was brought up many many times in the NG before and based on past > > occurences will most likely never change. > > I would hate to see enums lose the concept of *having* a base type and base > values because I do find that to be extremely useful (Haxe's enums don't > have a base type and, from direct experience with them, I've found that to > be a PITA too). But I feel very strongly that conversions both to and from > the base type need to be explicit. In fact, that was one of the things that > was bugging me about C/C++ even before I came across D. D improves the > situation of course, but it's still only half-way. > > >
Regarding the base type notion, I re-phrased my inccurate saying above in a reply to my post. I don't agree that enums should have a base type, enums should be distinct storng types. The numeric value should be a *property* of an enum member and not define its identity. Which is how it works in Java 5 where each each member is a singelton class. you should never do: void foo(int); foo(MyEnum.Bar); // this is bad design instead do: foo(MyEnum.Bar.value); // value is a regular property. This is also more flexible, since you could do things like: // assume I defined a Color enum foo(Color.Red.ordinal); bar(Color.Red.rgb); where foo belongs to an API that defines a a list of colors (red is 5)and bar belongs to a different API that uses the rgb value (red is 0xff0000) how would you do that with a C style enum?
