Implicit enum conversions are a stupid PITA

[yigal chripun]

Nick Sabalausky Wrote:

> "yigal chripun" <yigal100 at gmail.com> wrote in message 
> news:hobg4b$12ej$1 at 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?