The Lounge is rated PG. If you're about to post something you wouldn't want your
kid sister to read then don't post it. No flame wars, no abusive conduct, no programming
questions and please don't post ads.

Soren, I'm glad to read it was a good 'un you had. I've never been through a four hour interview like that and I reckon my longest was two hours. As long as you feel you interviewed well then it's equally likely they will have a similar feeling themselves after such a long session.

I interview well and the process never stresses me. My only uncomfortable one was my first ever interview after I graduated in '77 and was with a local authority. There were six people sitting behind two tables and a solitary chair in front of them. It felt like a scene from the movie The Manchurian Candidate. It wouldn't have been out of place if they'd tied my hands behind me back and set about me with a length of rubber hose. I didn't get the job which was fine.

Let us know how yours went.

If there is one thing more dangerous than getting between a bear and her cubs it's getting between my wife and her chocolate.

"I controlled my laughter and simple said "No,I am very busy,so I can't write any code for you". The moment they heard this all the smiling face turned into a sad looking face and one of them farted. So I had to leave the place as soon as possible."- Mr.Prakash One Fine Saturday. 24/04/2004

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.

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?

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!").

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