In C#, why can a single cast perform both an unboxing and an enum conversion?

Question

Normally, one would expect, and hope, that two casts are needed to first unbox a value type and then perform some kind of value type conversion into another value type. Here's an example where this holds:

  // create boxed int
  IFormattable box = 42;       // box.GetType() == typeof(int)


  // unbox and narrow
  short x1 = (short)box;       // fails runtime :-)
  short x2 = (short)(int)box;  // OK

  // unbox and make unsigned
  uint y1 = (uint)box;         // fails runtime :-)
  uint y2 = (uint)(int)box;    // OK

  // unbox and widen
  long z1 = (long)box;         // fails runtime :-)
  long z2 = (long)(int)box;    // OK (cast to long could be made implicit)

As you can see from my smileys, I'm happy that these conversions will fail if I use only one cast. After all, it's probably a coding mistake to try to unbox a value type into a different value type in one operation.

(There's nothing special with the IFormattable interface; you could also use the object class if you prefer.)

However, today I realized that this is different with enums (when (and only when) the enums have the same underlying type). Here's an example:

  // create boxed DayOfWeek
  IFormattable box = DayOfWeek.Monday;    // box.GetType() == typeof(DayOfWeek)


  // unbox and convert to other
  // enum type in one cast
  DateTimeKind dtk = (DateTimeKind)box;   // succeeds runtime :-(

  Console.WriteLine(box);  // writes Monday
  Console.WriteLine(dtk);  // writes Utc

I think this behavior is unfortunate. It should really be compulsory to say (DateTimeKind)(DayOfWeek)box. Reading the C# specification, I see no justification of this difference between numeric conversions and enum conversions. It feels like the type safety is lost in this situation.

Do you think this is "unspecified behavior" that could be improved (without spec changes) in a future .NET version? It would be a breaking change.

Also, if the supplier of either of the enum types (either DayOfWeek or DateTimeKind in my example) decides to change the underlying type of one of the enum types from int to something else (could be long, short, ...), then all of a sudden the above one-cast code would stop working, which seems silly.

Of course, the enums DayOfWeek and DateTimeKind are not special. These could be any enum types, including user-defined ones.

Somewhat related: Why does unboxing enums yield odd results? (unboxes an int directly into an enum)

ADDITION:

OK, so many answers and comments have focused on how enums are treated "under the hood". While this is interesting in itself, I want to concentrate more on whether the observed behavior is covered by the C# specification.

Suppose I wrote the type:

struct YellowInteger
{
  public readonly int Value;

  public YellowInteger(int value)
  {
    Value = value;
  }

  // Clearly a yellow integer is completely different
  // from an integer without any particular color,
  // so it is important that this conversion is
  // explicit
  public static explicit operator int(YellowInteger yi)
  {
    return yi.Value;
  }
}

and then said:

object box = new YellowInteger(1);
int x = (int)box;

then, does the C# spec say anything about whether this will succeed at runtime? For all I care, .NET might treat a YellowInteger as just an Int32 with different type metadata (or whatever it's called), but can anyone guarantee that .NET does not "confuse" a YellowInteger and an Int32 when unboxing? So where in the C# spec can I see if (int)box will succeed (calling my explicit operator method)?

Answer 1

When you use:

IFormattable box = 42; 
long z2 = (long)(int)box;

You are actually unboxing and then casting.

But in your second case:

IFormattable box = DayOfWeek.Monday; 
DateTimeKind dtk = (DateTimeKind)box;

You don't perform any casting at all. You just unbox the value. The default underlying type of the enumeration elements is int.

Update to refer to the real question:

The specification you mentioned in the comment:

The explicit enumeration conversions are:
...
From any enum-type to any other enum-type.

This is actually correct. We cannot implicitly convert:

//doesn't compile
DateTimeKind dtk = DayOfWeek.Monday;

But we can explicitly convert:

DateTimeKind dtk = (DateTimeKind)DayOfWeek.Monday;

It seems that you found a case when this is still required. But when combined with unboxing, only explicit conversion needs to be specified and unboxing can be ommited.

Update 2

Got a feeling that somebody must have noticed that before, went to Google, searched for "unboxing conversion enum" and guess what? Skeet blogged about it in 2005 (CLI spec mistake with unboxing and enums)

Answer 2

This is because they are actually represented as their underlying value type at runtime. They are both int, which follows the same situation as your failing cases - if you change the enum type in this situation, this would also fail.

As the type is the same, the action is simply unboxing the int.

You can only unbox values to their actual type, hence casting before unboxing does not work.

Update

If you create some code that casts int enumerations around with each other, you'll see that there are no casting actions in the generated IL. When you box an enum and unbox it to another type, there is just the unbox.any action which:

Converts the boxed representation of a type specified in the instruction to its unboxed form.

In this case it is each of the enums, but they are both int.

Update 2:

I've reached my limit of being able to explain what is going on here without much more in-depth research on my part, but I spotted this question:

How is it that an enum derives from System.Enum and is an integer at the same time?

It might go a little ways to explaining how enumerations are handled.