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
