"Tomek Sowiñski" <j...@ask.me> wrote in message news:hek1nv$2d6...@digitalmars.com... > Quick one: could the compiler enforce that enum values in order of > appearance are sorted? > > It could neatly guarantee no surprises with case ranges, like this one: > > enum Weird { One=1, Two=4, Three=3 } > > Now, case Weird.One: .. case Weird.Three: won't match Weird.Two. > > I'd agree that you don't see enums like Weird often. Then again, why rely > on a coding convention? This guarantee looks cheap to implement. > > Any reason against? > > Tomek
That could be a problem for this sort of scenario: A library starts out, in its initial prototype version with something like this: enum Actions { Jump = 1, Eat = 2 } Then in a later version a new feature is added: enum Actions { Jump = 1, Eat = 2, Drink = 3 } Then in each new verison more stuff gets added, over and over until it's like this: enum Actions { Jump = 1, Eat = 2, Drink = 3, Run = 4, Throw = 5, Worry = 6, Pout = 7, Jog = 8, Talk = 9 } Now it's become a mess, and needs to be organized, but at this point the library has gained enough widespread use that redoing the numbering would break a lot of code in non-obvious ways. There are plenty of ways to handle it, but it's nice to be able to just simply do this: enum Actions { // Athletic Jog = 8, Jump = 1, Run = 4, Throw = 5, // Nutritional Drink = 3, Eat = 2, // Social/Psychological Pout = 7, Talk = 9, Worry = 6 }