(moving http://goo.gl/ZISWwN to this group)
On 4/7/14, 3:41 PM, w0rp wrote:
Yeah, I've seen this happen before. I think we could actually introduce
a little more type safety on enums without a great deal of breakage. It
would be nice to have a final switch give you as much of a guarantee
about what it's doing as it can.
People use enums for things such as:
1. A discrete set of categorical values:
enum State { initial, waiting, running, done }
That's probably the most common use, and the one that prompted the
moniker "enum(eration)".
On these, virtually no arithmetic makes any sense. At most, some notion
of State successor(State) and State predecessor(State) may be sensible.
It would return the next/previously naturally occurring discrete value,
and would either throw, assert, or saturate at limits.
2. A collection of power-of-two flags that can be combined with "or" and
picked apart with "and".
enum AccountFlags { active = 1, overdrawn, hasDiscount = 4, primary = 8 }
Often, people who define these enums offer names for
frequently-encountered combinations of these flags:
enum AccountFlags { active = 1, overdrawn, hasDiscount = 4, primary = 8,
regular = active | primary }
For these kinds of flags, arithmetic doesn't make sense, only bitwise
operations: "|", "&", "^", and "~". A small algebra would be defined for
these operations.
3. A discrete set of categorical values, not all of which are named:
enum UserID : ulong { nobody, expired = ulong.max }
There would be no arithmetic/logic for such enums - they are only to
express categories. Comparisons for equality are needed; comparisons for
inequality may or may not be needed.
4. A "clone" of a type (usually numeric) that's generally used as a
helper for better typing.
enum Kilogram : double {}
enum Percent {}
All usual arithmetic is supposed to work. The enum acts as a subtype of
its base type.
5. Various combinations of the above, for example flags combined with masks:
enum AccountFlags { codeMask = 7, active = 8, overdrawn = 16,
hasDiscount = 32, primary = 64 }
(The account would start with a 3-bit code.) For such complex/irregular
uses it may make sense to require casting to the base type of the enum
before carrying general operations.
==========================
The current design is loose enough to accommodate all of the above uses,
probably too loose because it allows a bunch of nonsensical code to
compile. There are several questions to ask ourselves:
1. Is the current design damaging enough (= allows enough wrong/buggy
code to pass through) to warrant a breaking tightening?
2. To what extent can library-based approaches help?
3. What is the priority of improving enums in the larger picture of
other things we must do?
Andreiu
