![](https://secure.gravatar.com/avatar/01aa7d6d4db83982a2f6dd363d0ee0f3.jpg?s=120&d=mm&r=g)
On Jul 28, 2011, at 01:45 PM, Greg Ewing wrote:
If you mean that it's important for an enum *not* to have an ordering, I disagree. There are some use cases that benefit from having an ordering, and some that don't. For those that don't, personally I don't care whether it has an ordering or not.
Based on my recent experiment (see my other follow up), values-as-ints can have unintended side-effects. It's clear that making this change would be backward incompatible to my existing library, and I think it indicates that there are indeed separate use cases for ordered enums and unordered enums. I think if I were to accept values-as-ints as a new feature for my library, I'd want to make it a separate class. Yes, it complicates the library but maybe the two design requirements are just incompatible. -Barry