To me, enums in the .NET Framework 2.0 don’t feel like a polished feature. Writing
serious code with them is a descent into typecasting madness filled with the maniacal
laughter of bitwise ands and ors. Maybe the problem is that they are considered
"good enough" or simply "not interesting enough" to improve. I mean, what’s more
exciting to a compiler writer: enumerations or generics and lambda expressions?
It’s possible that enums haven’t been improved simply because of time constraints
or resources. But, in my humble opinion, it’s high time they deserved some love.
In this article, I offer up my list of potential improvements for .NET enums.
When possible, I present workarounds to implement the improvements with the current
or next version of the .NET framework.
Every enum has an underlying type that is one of the following: System.Byte,
System.Int16, System.Int32, System.Int64, System.SByte, System.UInt16, System.UInt32
or System.UInt64. This underlying type is used to store the actual numeric value
of the enum. By default, the underlying type is System.Int32 but a different underlying
type can be chosen when defining an enum:
If I want to convert a value from the above enum, I have to typecast:
Because Fruit is explicitly declared to have an underlying type of System.Byte,
it seems redundant to the extreme to require a typecast to a variable of that same
type. Especially, when implicit conversions are available in other situations where
a numeric value is guaranteed to fit inside another with no loss of precision:
I propose that enums are, at the very least, made implicitly convertible to their
underlying type. When converting from the underlying type to the enum, it seems
good practice and protective to require a typecast in case the enum doesn’t define
the appropriate named value.
I’m sure that the type safety police will be out in force on me for this but
this seems dogmatic just for the sake of being dogmatic. Some might argue that a
typecast improves readability in the above code because the type is visible on both
sides of the assignment but I would argue that the typecast actually adds visual
noise and makes it harder to read.
Currently, there is no way to constrain a generic type parameter to an enum.
In fact, it is illegal to constrain generic type parameter to inherit from System.Enum.
So, neither of these method declarations is legal:
We can constrain the generic type parameter to a struct since all enums implicitly
inherit from System.ValueType but runtime code must be written to further constrain
it to an enum:
The above code works fine except that it fails to generate a compile time error
because any struct can specified for T. So, this method will compile but fail spectacularly
if called like this:
In my opinion, the biggest benefit we would get from a new enum constraint for
generics is the possibility of a long overdue update to the System.Enum class. Currently,
every public static method on System.Enum declares its first parameter as a System.Type.
Each method has checks on this parameter to determine whether it is an enum and
throw the appropriate exception if it isn’t. In addition, any method that returns
an enum value or takes an enum value as a parameter uses System.Object. This causes
unnecessary boxing and unboxing operations which seem really wasteful considering
that enums are supposed to be lightweight.
Generic versions of the public static methods on System.Enum with an enum constraint
could remove the System.Type parameter and the runtime checks associated with it.
This allows client code to remove cumbersome typeof() operators. Also, because no
exceptions would be thrown, try/catch handlers could be removed from code that calls
these methods. In addition, the boxing and unboxing operations would be removed
as well as any previously required typecasts in calling code. In essence, there
would be benefits in both performance and code readability.
Today, we can achieve improved code readability by creating our own class that
wraps the System.Enum static methods with generic methods. Such a class actually
reduces performance slightly because it is another layer of indirection between
the client code and System.Enum. But, 99% of the time, readability would be preferred
over this minor performance hit.
In addition to updating the static methods on System.Enum, it would be useful
for the compiler to generate the necessary public static methods on the enum itself.
Compiler-generated methods aren’t a new concept to the .NET Framework. For example,
BeginInvoke, EndInvoke and Invoke methods are generated for delegates. I propose
generating all of the static methods that appear on System.Enum onto all new enums
at compile time. With this in place, code could be written like this:
With compiler-generated static methods on enums, users could forget about System.Enum
Please note that any enum inherits the static methods of System.Enum (even though
they don’t appear in Intellisense). So, the above code could be rewritten like this:
However, passing “typeof(Day)” into a method on the “Day” type seems pretty redundant
Giving developers the ability to declare instance methods on enums allow any
utility functions that operate on a particular enum to be place on the enum itself.
Here’s what I have to write today:
Here’s what I would like to be able to write:
Fortunately, there is a workaround if I have the LINQ preview installed. With
a little extra code, I can simulate instance methods using C# 3.0’s extension method
Using an extension method, I can achieve exactly the same client code but I have
to do a little bit more coding and create a new class to hold the method. It seems
to me that the C# team could add instance methods to enums for C# 3.0 by generating
extension methods at compile time.
To many, enums are perfectly satisfactory as they are. There really is very little
that can't do with an enum today. But, if you want to code them with elegance and
style, they'll need a bit of love first.
Page rendered at Monday, May 25, 2015 11:30:22 PM (Pacific Standard Time, UTC-08:00)
If feel a bit behind and need to catch up on WPF, this is the book.
Great book on F# containing from Beginner to Advanced. It even has chapters on more arcane features of the language, such as Computation Expressions and Quotations.
Because this book provides source code in Standard ML, it's a fantastic
resource for learning F#. One bit of warning: this book does not teach classic
data structures. While structures such as binomial heaps and red-black trees
are presented, it is assumed that the reader already knows and understands
The opinions expressed herein are my own personal opinions and do not represent
my employer's view in any way.