Consider the following API:
enum class WidgetFlavor
{
Vanilla,
Chocolate,
Strawberry,
Other,
};
WidgetFlavor GetWidgetFlavor(HWIDGET widget);
The idea here is that Widgets come in three flavors today, but we might add new flavors in the future, so we add an Other
value to cover any future flavors.
This is a problem.
Suppose we do indeed add a new flavor Mint
in the next version.
enum class WidgetFlavor
{
Vanilla,
Chocolate,
Strawberry,
Other,
Mint,
};
What flavor should you report if somebody calls GetWidgetFlavor
and the widget is mint?
If you return WidgetFlavor::
, then this will confuse code written with the Version 1 API, because they expected to get Other
for anything that isn’t vanilla, chocolate, or strawberry. The word “other” means “not mentioned elsewhere”, so the presence of an Other
logically implies that the enumeration is exhaustive.
On the other hand, you obviously should return WidgetFlavor::
because that’s why you added the value to the enum in the first place!
My recommendation is not to have an Other
at all. Just document that the enumeration is open-ended, and programs should treat any unrecognized values as if they were “Other”. Any code that uses this enumeration will therefore put all unrecognized values into an app-defined “Other” category on their own. Now you can add Mint
: New code will put minty widgets in a “Mint” category, and old code will continue to put them in the app=defined “Other” category.
If you are doing C++ then you should specify the type of enum base, if you are doing this trick.
If you are doing C then it’s best to add MaximumValue =2147483647 to ensure that different compilers and platforms wouldn’t change the layout of your class after you would add 256th flavor.
Because otherwise, according to the C/C++ standard, adding Mint to Vanilla, Chocolate, and Strawberry is legal, but adding Watermelon to that is no longer legal!
Rust has `#[non_exhaustive]` for this. https://doc.rust-lang.org/reference/attributes/type_system.html#the-non_exhaustive-attribute
I like the idea of an [Open] attribute to apply to enums.. similar to [Flags]. Documentation isn’t enough – there are so many de/serialization and ORM etc frameworks, that will throw exceptions when they see “flavor: 7”.
And this would help settle, once and for all, the ageless debate over whether or not it’s a breaking-change to add a value to an enum.
In the Apache Avro schema language, an enum type can have a default value, to which any unrecognized values are mapped during deserialization. This feature improves compatibility if a message is written using a newer version of the schema but is then read by software that uses an older version. Unlike C# and C++, Avro does not support casting arbitrary integers to an enum type.
I'm sorry for this unrelated comment, but I'd like to suggest an article topic, and I don't see a suggestion box anyplace.
Last year you shared with us the origins of the "Windows 3D Pipes" screensaver, which in part was a demonstration of OpenGL. I've been researching three interrelated screensavers from Plus! for XP that I believe were made to demonstrate Direct3D 8 shaders: "Mercury Pool", "Robot Circus" and "Sand Pendulum". Their team or project may have been called "MeSmer"; if there's any record of their work, or who it was that made the screensavers in the first place, I'd...
In C# I always make the first value (0) in an enum “Unknown” which should always be seen as an invalid value, and contextually different from “Other”. Then default(T) will always naturally set to this value in case someone forgets to assign to it. I’m willing to bet WidgetFlavor will probably be set to Vanilla much more often than it ought to…
Unknown is not the same as Invalid. Unknown means “I don’t know what it is.” Invalid means “I know what it is, but it’s not an allowed value.” For example, if somebody fills out a form and they leave the “country” field blank, then it’s Unknown. If they write “Saturn”, then it’s Invalid.