"yigal chripun" <yigal...@gmail.com> wrote in message news:hodruh$ai...@digitalmars.com... > 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? >
I see what you mean. Personally I don't care if it's handled as a property or as an underlying type that can only be obtained via an explicit cast, as long as you never get the "associated" value implicitly.
