Implicit enum conversions are a stupid PITA

[Nick Sabalausky]

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

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.