Wrong enum comparisons

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Mon May 28 12:21:14 PDT 2012


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.


Andrei


More information about the Digitalmars-d mailing list