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


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


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 next 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
prev sibling parent =?ISO-8859-1?Q?Tomek_Sowi=f1ski?= <just ask.me> writes:
dsimcha Wrote:

 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.


It's more like I haven't seen an example where keeping the values sorted would
do damage. But OK, the other replies feature such examples, so there's reason
to maintain the status quo.
Nov 25 2009