The need for Explicit Type Conversion in C#

Question

Consider the following code:

DerivedClass drbObj = (DerivedClass)obj;

Here obj is of type Object and this is reasonable since Object is the base type of every Class in C#.

Here, since the type of derObj is defined at compile time, what is the need to explicitly use type conversion here. Can't the compiler predict on it's own that it will be of DerivedClass. I understand that, the Conversion type doesn't have to match the Derived type, but for practical purpose, it will only be as useful as the Derived type.

Could someone explain with a small, hypothetical example, as to why the Explicit Type Conversion is necessary when a reference of type Object is being assigned to a derived class.

From what I know, in C, there is no need to do perform Explicit type conversion from void* to any pointer and the compiler can handle it, based on the type of the pointer to which the converted value is being assigned.

Answer 1

The reason why you have to do this is pretty simple:

Because that's the way the language was designed.

While yes, the C# designers could have decided to infer that your intent was to cast obj based solely on your declaration, they chose not to do so, probably because such an inference would cause more problems than it solved.

I can think of two reasons why they might have chosen not to infer the cast to DerivedObj:

1) Because it's inconsistent. Though for assignment (as in your example) it may seem logical to perform the inference, there are a ton of situations you would need to perform the cast explicitly, and making the casting behavior consistent makes the language conceptually simpler. For example, let's say you were writing a piece of code that needed to set the obj's ID to 5, knowing ahead of time that it was a DerivedObj. You'd still have to do the cast:

((DerivedObj)obj).ID = 5;

2) Because it's dangerous. Performing the cast at assignment is an "are you sure?" kind of check which makes you think twice about what the object really is before assigning. I would say that's a feature of the language, and definitely not worth a special-case casting behavior just for assignment. In fact, if you really created obj by saying obj = new object() somewhere, the cast will fail anyway.

Answer 2

Can't the compiler predict on it's own that it will be of DerivedClass.

No? How on earth would it predict that? You want it to solve the Halting problem? Objects may be useless (and a shitty, shitty design) but there are millions of classes derived from Object. How would the compiler know which one to pick?

The reason the cast is necessary is because it could fail at run-time, and the compiler wants to know that you're sure. Explicit casting is much safer than implicit casting.

From what I know, in C, there is no need to do perform Explicit type conversion from void* to any pointer and the compiler can handle it, based on the type of the pointer to which the converted value is being assigned.

That's a bad thing, not a good thing, and conversion != casting. Casts are bad. Try not to use them.

Answer 3

When asking "why," it is important to ask two sub-questions. What does this gain us, and what does this lose us?

1. What does this gain us?

Nothing, actually. I would guess you want to cut down on copy paste. That's an admirable goal, but the idiomatic C# way to write this is actually:

var drbObj = (DerivedClass)obj;

2. What does this lose us?

Compile-time checks on runtime safety. The compiler usually doesn't know for sure that obj will always hold a reference to an instance of the derived class. It also doesn't know whether you are willing to risk an uncaught type-casting exception here. It doesn't know how to handle this situation at compile time.

When you put in the explicit cast, you are resolving that problem. You are explicitly telling the compiler, "I know that there is a DerivedClass instance in here, and I am willing to suffer an exception if I'm wrong." The compiler then does what you told it. It would be quite risky (runtime crashes without warning? no thanks!) to let the compiler decide to do that on its own.

Answer 4

The C# language uses casting syntax to mean a number of different things, depending upon the operand and result types. The meaning here is "I think the operand is a reference to a thing of type X, and I would like to make it available to something requiring a reference of type X; throw an exception if the thing isn't of the proper type.

When trying to write any sort of sane code, it's important to have at least some kinds of statements which can be guaranteed not to throw any exception unless a thread is rudely aborted. Given a local variable x of some reference type, it's important that if the evaluation of some expression can be guaranteed not to throw an exception, so can the statement x = expression;.

If x is of a type more derived than y, the expression (typeOfX)y; might throw an exception if y cannot be cast to the type of x, but the statement x = (typeOfX)y; obeys the rule that an assignment to a local variable cannot throw an exception once the evaluation of the right-hand argument is complete. Since downcasts are a situation where exceptions might get thrown, requiring a programmer to write x = (typeOfX)y; rather than just x = y; makes clear that the statement might throw an exception.