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 e
== Quote from Tomek_Sowi�ski (j...@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.Thre
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 pr
"Tomek Sowiñski" 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
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
