Cast vs 'as' operator revisited

I know there are several posts already concerning the difference between casts and the as operator. They all mostly restate the same facts:

• The as operator will not throw, but return null if the cast fails
• Consequently, the as operator only works with reference types
• The as operator will n开发者_JAVA百科ot use user-defined conversion operators

Answers then tend to debate endlessly the how to use or not use the one or the other and the pros and cons of each, even their performance (which interests me not at all).

But there is something more at work here. Consider:

static void MyGenericMethod<T>(T foo)
{
    var myBar1 = foo as Bar;  // compiles
    var myBar2 = (Bar)foo;    // does not compile ('Cannot cast expression of
                              // type 'T' to type 'Bar')
}

Please never mind whether this obviously contrite example is good practice or not. My concern here is the very interesting disparity between the two in that the cast will not compile whereas the as does. I really would like to know if anyone could shed some light on this.

As is often noted, the as operator disregards user-defined conversions, but in the above example, it is clearly the more capable of the two. Note that as far as the compiler is concerned, there is no known connection between the (unknown at compile-time) type T and Bar. The cast is entirely 'run-time'. Should we suspect that the cast is resolved, wholly or partly, at compile time and the as operator not?

By the way, adding a type constraint unsurprisingly fixes the cast, thus:

static void MyGenericMethod<T>(T foo) where T : Bar
{
    var myBar1 = foo as Bar;  // compiles
    var myBar2 = (Bar)foo;    // now also compiles
}

Why does the as operator compile and the cast not?

---

To address your first question: it is not just that the as operator disregards user-defined conversions, though that is relevant. What is more relevant is that the cast operator does two contradictory things. The cast operator means either:

1. I know that this expression of compile-time type Foo will actually be an object of runtime-type Bar. Compiler, I am telling you this fact now so that you can make use of it. Please generate code assuming that I am correct; if I am incorrect, then you may throw an exception at runtime.

2. I know that this expression of compile-time type Foo will actually be of runtime type Foo. There is a standard way of converting some or all instances of Foo to an instance of Bar. Compiler, please generate such a conversion, and if it turns out at runtime that the value being converted is not convertible, then throw an exception at runtime.

Those are opposites. Neat trick, to have an operator that does opposite things.

The as operator by contrast only has the first sense. An as only does boxing, unboxing and representation-preserving conversions. A cast can do all of those plus additional representation-changing conversions. For example, casting int to short changes the representation from a four-byte integer to a two-byte integer.

That's why "raw" casts are not legal on unconstrained generics; because the compiler does not have enough information to figure out what kind of cast it is: boxing, unboxing, representation-preserving or representation-changing. The expectation of users is that a cast in generic code has all the semantics of a cast in more strongly typed code, and we have no way to generate that code efficiently.

Consider:

void M<T, U>(T t, out U u)
{
    u = (U)t;
}

Do you expect that to work? What code do we generate that can handle:

M<object, string>(...); // explicit reference conversion
M<string, object>(...); // implicit reference conversion
M<int, short>(...); // explicit numeric conversion
M<short, int>(...); // implicit numeric conversion
M<int, object>(...); // boxing conversion
M<object, int>(...); // unboxing conversion
M<decimal?, int?>(...); // lifted conversion calling runtime helper method
// and so on; I could give you literally hundreds of different cases.

Basically we would have to emit code for the test that started the compiler again, did a full analysis of the expressions, and then emitted new code. We implemented that feature in C# 4; it's called "dynamic" and if that's the behaviour you want, you can feel free to use it.

We have none of these problems with as, because as only does three things. It does boxing conversions, unboxing conversions, and type tests, and we can easily generate code that does those three things.

---

Should we suspect that the cast is resolved, wholly or partly, at compile time and the as operator not?

You gave the answer yourself at the beginning of your question: "The as operator will not use user-defined conversion operators" - meanwhile, the cast does, which means it needs to find those operators (or their absence) at compile time.

Note that as far as the compiler is concerned, there is no known connection between the (unknown at compile-time) type T and Bar.

The fact that the T type is unknown means the compiler can't know whether or not there is no connection between it and Bar.

Note that (Bar)(object)foo does work, because no type can have a conversion operator to Object [since it is the base class of everything], and the cast from object to Bar is known to not have to deal with a conversion operator.

---

It is a matter of type safety.
Any T cannot by convert to a Bar, but any Tcan be "seen" as a Bar since the behavior is well defined even if there is no conversion from T to Bar.

---

The first compiles simply because that's how the as keyword is defined. If it can't be cast, it will return null. Its safe because the as keyword by itself won't cause any runtime issues. The fact that you may or may not have checked for the varible to be null is another matter.

Think of as as a TryCast method.

---

The compiler does not know how to generate code that will work for all cases.

Consider these two calls:

MyGenericMethod(new Foo1());
MyGenericMethod(new Foo2());

now assume that Foo1 contains a cast operator that can convert it to a Bar instance, and that Foo2 descends from Bar instead. Obviously the code involved would depend heavily on the actual T you pass in.

In your particular case you say that the type is already a Bar type so obviously the compiler can just do a reference conversion, because it knows that is safe, there's no conversion going on or needed.

Now, the as conversion is more "exploratory", not only does it not consider user conversions, it explicitly allows for the fact that the cast is meaningless, so the compiler let that slide.