Wrong enum comparisons

[Jonathan M Davis]

On Monday, May 28, 2012 14:21:14 Andrei Alexandrescu wrote:
> On 5/28/12 1:07 PM, foobar wrote:
> > It depends on what exactly the general concept is, is this a predefined
> > set of values or is it an ordered list. I'd argue that the set is more
> > general and we shouldn't force an ordering when one isn't strictly
> > required. Of course, the programmer should be able to add an ordering
> > when it's required.
> 
> Ascribing ordinal values is not ordering.
> 
> > How to implement an order:
> > IMO casts usually indicate code smell.
> > I think something like Color.Red.ordinal states the intention much
> > better than a cast.
> 
> Well ordinal could always be a function that does the cast...
> 
> > Could you please explain the issues you see in Java's Enum that cause
> > you to reject such a design?
> 
> Too big for what it does. Not worth getting into details as I don't have
> a strong opinion or one of much consequence.
> 
> At the end of the day, it is fairly clear to me that D's enum is in no
> interesting point on the convenience/safety tradeoff scale, and doesn't
> offer anything worth its presence in the language. It's just a bit less
> broken than typedef, which was just egregious. No surprise there -
> aspects of the language that received attention (e.g. floating point)
> turned out well whereas those that didn't (either through incomplete
> analysis or inheriting a bad design) turned out rather badly. I'd put
> typedef (good thing it's gone), lazy, and enum in the latter category.

enum does need some work, but I think that the fact that it can be both built-
in types such as int as well as user-defined structs is great. It essentially 
gives us the best of both worlds (basic enums such as in C/C++ and more 
complex types as in Java). It's some of the minor details where things tend to 
not work as well as would be nice (e.g. some of the arithmetic that's 
considered legal on enums which are integral values).

- Jonathan M Davis