Cast vs 'as' operator revisited

Question

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 not 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?

Participation

It looks to me like foo as Bar is specifying the type parameter, whereas (Bar)foo is attempting a cast on an unspecified type T. That's why the second example works; you've constrained the type parameter to the castable type. The first example doesn't compile because foo is not guaranteed to be type-safely castable to Bar. – Morice

Why does the as operator compile and the cast not? – Participation

@Robert: I don't see what you're saying. That should throw an InvalidCastException, or the as shouldn't compile either. – Bowknot

@robert: So you're saying that the cast operator requires such a guarantee and the as operator not? Why? Just an arbitrary design decision by the compiler team? – Participation

If you specify a Type T as the thing to cast, there's no compile-time guarantee that the actual type you specify at run-time is going to be castable to Bar. Generics are compile-time constructs; the check for type safety is done at compile time. Since (Bar)foo cannot be checked for type safety at compile time, a compile error occurs. But using the as operator specifies the type; it constrains the run-time type to be Bar. So no compile error occurs, because the compiler can deduce that Bar is castable. – Morice

@Daniel: Try it, the as compiles, the cast not. Exeptions are irrelevant here, as the code doesn't compile and hence will never run. – Participation

possible duplicate of Cast generic property of type T up to a known inheriting type – Extravagant

@Robert: I know that, and would expect exceptions at runtime, but if the method were not generic and foo were of type object, the cast would compile (and possibly throw). Casting an object is not 'guaranteed' either. But it compiles. – Participation

Working with object does not require compile-time type safety. Working with generic T parameters does. – Morice

Answer 1

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.

Aquamarine

Congrats on getting 100K! BTW, where is this in the spec? I couldn't find it. – Bowknot

@SLaks: Thanks! The bit in the spec that says that casts from type parameter types to unrelated types is "if no explicit conversion exists from E to T, a binding-time error occurs." No explicit conversion exists from T to Bar, so the cast is illegal. – Aquamarine

A beautiful exposition. I did suspect some hidden depths there, given the several meanings of 'conversion'. Thanks for the insight! – Participation

Answer 2

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.

Pallaton

Answer 3

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.

Tetragonal

Answer 4

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.

Alcaic

Answer 5

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.

Disciplinary