The rules of generics and type constraints

Question

Just out of curiosity, why does the compiler treat an unconstrained generic type any differently than it would typeof(object)? ``` class Bar { } class Foo { void foo(object thing) { ((Bar)thing).ToString(); } } class Foo<T> { void foo(T thing) { ((Bar)thing).ToString(); } } ``` In the above, casting "T thing" to Bar results in a compiler error. Casting "object thing" to Bar however is something the compiler lets me do, at my own risk of course. What I don't see is why. In .net object after all is a catch-all and the run-time type could be a boxed value or an object of any type. So I don't see what logical reason there is for the compiler to differentiate between the two cases. The best I can do is something like "the programmer would expect the compiler to do type checking with generic types, but not with object". :) Is that all there is to it? Btw, I am aware that I can still get my cast done in the Foo case, by simply writing ``` ((Bar)(object)thing).ToString(); ``` I just want to u…

Accepted Answer

The significance here is `object`. If the first example was anything other than `object` it would behave the same. Basically, what you are saying at the moment here:

```
(Bar)thing
```

is: "convert a `T` to a `Bar`"; which is nowhere near legal in the general case. By adding `object` you make it:

```
(Bar)(object)thing
```

which is "convert a `T` to an `object`..." - which is always legal, since `object` is the root of all managed types; and note this may invove a box - "...and then cast the `object` as a `Bar`" - again; it is always legal at compile time, and involves a type-check ("unbox-any") at runtime.

For example: suppose `T` is `DateTime`...

```
DateTime thing = ...
Bar bar = (Bar)(object)thing;
```

is perfectly valid; sure it'll fail at runtime, but: this is the scenario you need to keep in mind.

The rules of generics and type constraints

Solution

Problem