|
Part of an application I work on involves navigation through a series of documents, previously the navigate function looked like:
void NavigateTo(int document)
but as part of a redesign that made a single numeric index lose it's meaning, I changed it to
void NavigateTo(NavigationDirection direction)
where NavigationDirection is an enum consisting of Forward and Backward. As expected, the change caused some compilation errors where it was being called, because C# doesn't allow implicit conversion of int to enum. Having written the section of code it was in, I was pretty sure I knew where all the calls were, and the compiler seemed to agree...but the navigation was acting funny, it started at the second document. Debugged it, and found a third call to the function, that looked like this:
NavigateTo(0);
and 0 was the value of Forward, which was then moving it to the 2nd document, added a third value to the enum, None, since the first document was already being loaded in a new way, and this was just moving past it (the navigation has some side effects, loading other things related to the document, so the call was still needed...it makes more sense in the actual code, I'm just simplifying it). But hold on, I thought there wasn't an implicit conversion from int to enum types in C#?
So I played around with it a bit, and here's what I discovered: ints are not implicitly convertible to enum types (as I thought)...but const ints are 0 is! Both integer literals, and const int variables, as long as the value maps to a value in the enum (if it had been a number greater than 1 other than 0, I would have had the expected compiler error). While I understand how the compiler can implement this, I don't understand why they would, it seems to go against the C# language itself. I don't think you could even write your own implicit conversion that behaves the same way, since from what I can tell C# doesn't generally make a distinction between const and non-const versions of the same type for the purposes of parameters (e.g. int and const int can be used interchangeably), with the exception of ref and out...but that causes restriction in the reverse direction (only non-const).
Seems like an odd language design choice to me 
EDIT: looks like I jumped the gun a little on this one, apparently, it only works for 0. Which is probably worse...
|
|
|
|
|
|
There was something brought up there I didn't test...it is exclusive to 0. That is even worse. Even if I explicitly set the values of the enum so none of them are 0, 0 is still valid, but other ones are not even if they exist...but it gets worse. If there isn't one for 0, it just becomes the value 0 (which won't likely be handled by a function expecting a proper enum value), but if it does it becomes that enum value instead.
Wat.
|
|
|
|
|
According to this, zero is basically the enum version of a default/null value. Not that it makes any more sense, but that seems to be the reason they allow for zero as a value for enums.
|
|
|
|
|
My problem with that treatment is that I might already be using 0 (and in most cases, I am, because I don't explicitly assign values if it isn't flags, and the first one will always be 0), and while I often declare a null-ish value in enums, there are plenty of cases where that also doesn't make sense. Something more explicit like "Enum.Null" would be fine, then it could be it's own type that's explicitly convertible to enum.
|
|
|
|
|
Having had a year to ponder it I suspect it's related to default, as in default(T) in a generic class. When T is an enumeration type the compiler has to get the default for the underlying type and that then has to be cast to the enumeration type -- but why the compiler can't use an explicit cast I don't know -- laziness I suspect. 
|
|
|
|
|
Believe it or not that's what I would expect.
Remember that C# has its roots in C++ and in C++ everything can be validly initialised with a 0. It's an odd rule and one that seldom gets mentioned but we actually make a deal of use it to do things like initializing structures with {0} apart from every null initialised pointer prior to C++11's nullptr constant, which evaluates to, you guessed it, 0.
In C++ Enums have no choice but to participate so enum types can also always be initialised with 0. It's so rare for enums not to have a zero valued member and for it to be an issue that I've never even considered what happens when an Enum with no zero valued member is initialised with 0 but I would expect it to 'work' in the sense of not raising more than a minor warning and to run and for the variable to have the value 0.
"The secret of happiness is freedom, and the secret of freedom, courage."
Thucydides (B.C. 460-400)
|
|
|
|
|
But in C++ (if I remember correctly), all integer types are implicitly convertible to enum. Then 0 assignment becomes expected behavior. In a language that explicitly prevents this, having one magic value that works does not make sense to me.
Edit: Also, it doesn't work for other classes or structs either, so why should enum be special?
|
|
|
|
|
I agree it doesn't make any sense in C# but my guess is its a hangover from C++ that still hasn't quite gone away rather than a deliberate design decision.
"The secret of happiness is freedom, and the secret of freedom, courage."
Thucydides (B.C. 460-400)
|
|
|
|
|
It seems hard to assume it wasn't, especially because it's not a feature of any other type (without implicit conversion explicitly defined...that's sounds kind of awkward). Kind of hard to end up with the one exception on accident. And of course, being Microsoft, with their huge love of never ever breaking compatibility unless there is no other way, even if it wasn't intentional, it's not likely to ever change now ("What if someone's code depends on it? Can't inconvenience those people using it on purpose!").
|
|
|
|
|
lewax00 wrote: it's not likely to ever change now
Very true. It's total speculation but I'd hazard it got in to C# in the first place due to being coded as a exceptional case in the C++ compiler being ported, sneaked through and got shipped and like much else that Microsoft has accidentally released not quite perfected, they were immediately stuck with it.
I love their obsession with backward compatability after all how else would we have ended up with a Win32 API with 17 different functions for answering the question "How long is this piece of string going to be when I paint it on the screen?", with anything between 1 and 3 of them actually giving the correct answer depending on the version, the screen and the current alignment of Mars with the Moon. 
"The secret of happiness is freedom, and the secret of freedom, courage."
Thucydides (B.C. 460-400)
|
|
|
|
|
I don't write in C#, (only C,C++, Java etc) but this strikes me as being very similar behaviour to early C/C++ compilers where 0 was acceptable as a NULL value for almost any pointer to any type of object. I wonder if that usage effectively crept through into C# in this particular case?
|
|
|
|
|
I'd call them "integer literal" and "integer variable" rather than "integer const" and "integer variable". But yeah, that's an interesting nuance, and I don't think implicit conversion operators can make a distinct between literals/variables.
However, expression trees might be able to (though that is a runtime construct, not a compile time one).
Also, I wonder if Roslyn would allow for knowledge of literals/variables.
|
|
|
|
|
A constant integer and and integer literal are two different things though (at compile time anyways, they may not be by run time, depending on what the compiler does with them). And both are valid in this context, e.g. in
const int i = 0;
EnumType e0 = 0;
EnumType e1 = i;
both assignments to the EnumType are valid.
|
|
|
|
|
|
lewax00 wrote: looks like I jumped the gun a little on this one, apparently, it only works for
0. Which is probably worse...
However that isn't guaranteed.
I have a test scenario where the MSMQ API would return an enumerated value (not zero) which was not in fact part of the enumeration.
My supposition is that it is an unmanaged code conversion somewhere that wasn't accounted for.
|
|
|
|
|
Well only 0 works at compile time anyways from what I can tell...guess I should assume switch statements using enums might actually receive other values too, and include a default case from now on, just in case, since the CLR clearly doesn't have an issue with passing other values as enums.
|
|
|
|
|
Interesting! I suppose this is one of the reasons for the existence of the CA1008 code analysis rule.
Quote:
CA1008: Enums should have zero value[^]
Cause: An enumeration without an applied System.FlagsAttribute does not define a member that has a value of zero; or an enumeration that has an applied FlagsAttribute defines a member that has a value of zero but its name is not 'None', or the enumeration defines multiple zero-valued members.
Perhaps by specifying a default value with a "no action" behavior it would have been easier to spot this one, or at least it wouldn't lead on the weird behavior (you would have to explicitly handle or ignore the .None values).
|
|
|
|
|
But that only applies to enums with [Flags], and I always add a None to those (if only to make it easier to check if there are no flags set). In non-flags cases, None doesn't always make sense (e.g. you use enums to look up settings in order to make them both easily readable and limited in value, plus easily convertible to integers for binary storage or strings for human readable storage, but a "None" setting doesn't really make sense, what it the current value of "None"?) I guess in those cases you could just throw an exception, but part of the point of using an enum is that you shouldn't be able to receive invalid values.
|
|
|
|
|
So it seems like in your case it would be safest to setup your enum like:
{None=0, Forward=1, Backward=2}
If you ever receive a None, you could email yourself a stacktrace.
Also, include a default case with similar behavior.
|
|
|
|
|
That's what I ended up doing, but I actually needed that None value at the point where I was using 0, because the other two didn't make sense there. I might add one for "Beginning" instead (it makes a little more sense conceptually than "None" at the point it's at).
|
|
|
|
|
Well as some people say, if it's not a bug, it's a feature... 
|
|
|
|
|
I always thought this part of C# was kind of hokey, but after reporting it to Microsoft as a bug (derp), and it getting escalated to the framework team, it was revealed, it is part of the spec:
http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-334.pdf[^] (The C# Specification), page 136 states:
"An implicit enumeration conversion permits the decimal-integer-literal 0 to be converted to any enum-type."
So the short answer is, it's in the spec.
The long answer is (from Habib, here: http://stackoverflow.com/questions/14950750/why-switch-for-enum-accepts-implicit-conversion-to-0-but-no-for-any-other-intege[^])
At compile time 0 is known as the default value for an enum. No other value is explicitly known, and that is why no other value is allowed to be substituted.
In fact, you can try some sample code out for yourself:
class Program
{
enum Direction { left = 1, right = 2 }
static void Main(string[] args)
{
Direction d = 0;
Console.WriteLine("Direction: " + Enum.GetName(typeof(Direction),d));
Console.ReadLine();
}
}
Note that even though we've explicitly excluded 0 from our example, the code still compiles and works happily returning "" for the label corresponding to 0. It's always going to be there, and that's why 0 is allowed an implicit cast.
=============================
I'm a developer, he's a developer, she's a developer, Wouldn't ya like to be a developer too?
|
|
|
|
|
Chadwick Posey wrote: At compile time 0 is known as the default value for an enum. No other value is explicitly known, and that is why no other value is allowed to be substituted.
That seems odd to me, because the actual enums are known (e.g. "Forward" and "Backward" in my example), so knowing the values as well shouldn't be difficult, because it clearly parsed them already.
But that's the clearest statement from the spec I've seen about it, thanks for confirming that 
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
