将约束的通用类型传递给非通用方法

Question

Why can't I pass an instance of this class...

class Item<T> where T : Thing { }

...into this method:

void DoSomething(Item<Thing> item);

Since I've constrained Item<T> to be an Item<Thing> , it should be safe to cast before sending my item through to DoSomething - but why doesn't the framework handle this?

Answer 1

Assuming you have a class:

public class SomeOtherThing : Thing { }

An Item<SomeOtherThing> can not be cast to an Item<Thing> . They are not the same.

Let's assume for a moment that item looks something like this:

public class Item<T>
{
    public T Value { get; set; }
}

DoSomething might then do something like:

void DoSomething(Item<Thing> item)
{
    item.Value = new Thing();
}

If you pass in an Item<SomeOtherThing> to DoSomething you have now just assigned a new Thing to Value , but value is a property of type SomeOtherThing , you cannot set a Thing object to it . This would have then broken the type system. The compiler knows that this is an option. Because of this (and any number of other operations that have the same fundamental problem) a Item<SomeOtherThing> can not be cast to an Item<Thing> .

So, what can you do?

Well, if you control the definition of DoSomething , perhaps it too should be generic.

If DoSomething looks like this:

void DoSomething<T>(Item<T> item)
    where T : Thing
{    }

Then you can call it with an Item<SomeOtherThing> since the operations that previously would have caused problems are no longer valid from within DoSomething .

Answer 2

Imagine

class Derived : Thing {}

The Item<Derived> is not assignable to Item<Thing> .

Answer 3

you need to be a little more specific in the method declaration like so;

void DoSomething<T>(Item<T> item)
    where T : Thing
{
    // now your method knows that T must be of time Thing and you can use it
}

Answer 4

The issue you have is that your method is specific to Item<Thing> , and Item<Something> is not a valid argument. C# does not support generic class covariance. You have several options.

The "easiest" thing to do is to simply make your method generic and add a constraint to Thing. This would be the first advised approach.

void DoSomething<T>(Item<T> item) where T : Thing
{
}

This will grant you access to all members of Thing as applicable, while still having a method that can cater to all subclasses.

Another option with more limitation is to have a non-generic base to Item<Thing> that is simply Item . (In it, wherever you were previously exposing T, you would expose object . Think: IEnumerable<T> : IEnumerable .)

void DoSomething(Item item)
{
}

Your method would simply expect Item and you could work with it. But if you have a specific requirement to work with Thing , it is a bit more delicate, you would need to cast as appropriate, but you also face the possibility that someone passes an instance that isn't an Item<T> where T is a Thing.

One other option is to leave the signature of the method alone and convert from a class to an interface, which allows you to use covariance. (Co/contravariance is supported in .NET 4.0 for interface and delegate types.)

interface Item<out T> 
{
    T Get();
    // void Set(T foo); // invalid  
}

Again, the issues here are that 1) you would need to change your type (obviously) but 2) you would be limited to only exposing T in output positions. Notice the Get() method is supported. A Set(T) method is not, because T is an input, which makes the interface not covariantly valid. (Imagine passing in an Item<Something> , and your method trying to call Set with SomeOtherThing . Both are Things , but clearly the second is not appropriate for the first.) So if you need to support T as both outputs and inputs, you could not utilize this approach.