Sadly, no. There seems to be two basic camps: those that think an enum should be valueless, and have nothing to do with an integer besides using it to select the appropriate enumerator (that just looks strange -- I hope you're right Stephen!); and those for whom the integer is an integral part of the enumeration, whether for sorting, comparing, selecting an index, or whatever.

To be honest, I really don't think these two camps are as irreconcilable as lots of people seem to be treating them. I don't think either view is necessarily wrong, and I firmly believe that we can find a common ground that works for both ways of approaching this issue. More importantly, however, I believe we must try to find some way to coexist or anything we come up with will be fundamentally inadequate for a substantial portion of the community, and in that case, I don't think it belongs in the stdlib. If we can't compromise a bit, I think we're all doomed to failure.

I do recognize that the issue of transitive equality is something we're going to need to work out. One thing I think folks need to keep in mind, though, is that that issue really has nothing to do with int-enums vs. valueless-enums at all. It will still be a point of contention even if we go with solely the "enums are ints" way of looking at things, so that really won't solve it. (The fundamental issue is: int-enums are (by definition) both ints, and named-objects. When not explicitly or implicitly being used as an int, should they still behave like ints first and named-objects second, or should they be named-objects first and ints second? Both ways have some problems, and we will ultimately need to choose which set of problems will be the least annoying in the long term, but that's a completely separate discussion than the int/valued/valueless question, IMHO.)

--Alex