www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Sort enum values, please

reply =?ISO-8859-1?Q?Tomek_Sowi=f1ski?= <just ask.me> writes:
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
Nov 25 2009
next sibling parent dsimcha <dsimcha yahoo.com> writes:
== Quote from Tomek_Sowiński (just ask.me)'s article
 Quick one: could the compiler enforce that enum values in order of appearance

 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

 Any reason against?
 Tomek

Have you ever seen this issue come up in practice in a real program? I'd be hesitant to add even a small amount of complexity and restrictions to a language to prevent some class of bugs that's only a theoretical possibility and almost never occurs in real-world code.
Nov 25 2009
prev sibling next sibling parent BCS <none anon.com> writes:
Hello Tomek,

 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.
 

My current programming project (in C++ as a result of the CS class it's for) has a rather common enum where this would be a bother as it has several identifiers for the same values. Having to sort them would make working with them a pain.
 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
 

Nov 25 2009
prev sibling parent "Nick Sabalausky" <a a.a> writes:
"Tomek Sowiński" <just ask.me> wrote in message 
news:hek1nv$2d67$1 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 }
Nov 25 2009