Compiler fails converting a constrained generic type

问题

I have a class that has a Generic type "G"

In my class model i have

public class DetailElement : ElementDefinition

Let's say i have a method like this

        public void DoSomething<G>(G generic)
            where G : ElementDefinition
        {
            if (generic is DetailElement)
            {
                ((DetailElement)generic).DescEN = "Hello people"; //line 1
                //////
                ElementDefinition element = generic;
                ((DetailElement)element).DescEN = "Hello again"; //line 3
                //////
                (generic as DetailElement).DescEN = "Howdy"; //line 5
            }
            else
            {
                //do other stuff
            }
        }

Compiler reports one error in line 1:

Cannot convert type 'G' to 'DetailElement'

But line 3 works fine. I can workaround this issue by doing the code written in line 5.

What i would like to know is why does the compiler reports the error in line 1 and not the one in line 3, given that, as far as i know, they are identical.

edit: I am afraid i might be missing some important piece of the framework logic

edit2: Although solutions for the compiler error are important, my question is about why the compiler reports an error on line 1 and not in line 3.

回答1:

If G was constrained to be a DetailElement (where G : DetailElement) then you can go ahead and cast G to ElementDefinition, i.e., "(ElementDefinition) generic". But because G might be another subclass of ElementDefinition other than DetailElement at run-time it won't allow it at compile-time where the type is unknown and unverifiable.

In line 3 the type you cast from is known to be an ElementDefinition so all you're doing is an up-cast. The compiler doesn't know if it will be a succcesful cast at run-time but it will trust you there. The compiler is not so trusting for generics.

The as operator in line 5 might also return null and the compiler doesn't statically check the type to see if it's safe in that case. You can use as with any type, not just ones that are compatible with ElementDefinition.

From Can I Cast to and from Generic Type Parameters? on MSDN:

The compiler will only let you implicitly cast generic type parameters to object, or to constraint-specified types.

Such implicit casting is of course type safe, because any incompatibility is discovered at compile-time.

The compiler will let you explicitly cast generic type parameters to any interface, but not to a class:
   interface ISomeInterface {...}
   class SomeClass {...}
   class MyClass<T> 
    {
      void SomeMethod(T t)
       {
         ISomeInterface obj1 = (ISomeInterface)t;//Compiles
         SomeClass      obj2 = (SomeClass)t;     //Does not compile
       }
    }
However, you can force a cast from a generic type parameter to any other type using a temporary object variable
 void SomeMethod<T>(T t) 
  { object temp = t;
    MyOtherClass obj = (MyOtherClass)temp;  
  }
Needless to say, such explicit casting is dangerous because it may throw an exception at run-time if the concrete type used instead of the generic type parameter does not derive from the type you explicitly cast to.

Instead of risking a casting exception, a better approach is to use the is or as operators. The is operator returns true if the generic type parameter is of the queried type, and as will perform a cast if the types are compatible, and will return null otherwise.
public void SomeMethod(T t)
 {
   if(t is int) {...}

   string str = t as string;
   if(str != null) {...}
 }

回答2:

Generally, upcasting is a code smell. You can avoid it by method overloading. Try this:

public void DoSomething(DetailElement detailElement)
{
    // do DetailElement specific stuff
}

public void DoSomething<G>(G elementDefinition)
    where G : ElementDefinition
{
    // do generic ElementDefinition stuff
}

You can then take advantage of method overloading by using this code:

DetailElement foo = new DetailElement();

DoSomething(foo); // calls the non-generic method
DoSomething((ElementDefinition) foo); // calls the generic method

回答3:

Shouldn't your where clause be "where G : DetailElement"?

In the code you've written, a DetailElement is an ElementDefinition, but an ElementDefinition is not necessarily a DetailElement. So the implicit conversion is illegal.

Are there other types of ElementDefinition that you might pass into this method? If so, they'll throw an exception when you try to cast them into DetailElement instances.

EDIT:

Okay, so now that you've changed your code listing, I can see that you're checking the type to make sure it really is a DetailElement before entering that block of code. Unfortunately, the fact of the matter is that you can't implicitly downcast, even if you've already checked the types yourself. I think you really ought to use the "as" keyword at the beginning of your block:

DetailElement detail = generic as DetailElement;
if (detail == null) {
   // process other types of ElementDefinition
} else {
   // process DetailElement objects
}

Better yet, why not use polymorphism to allow each kind of ElementDefinition to define its own DoSomething method, and let the CLR take care of type-checking and method invocation for you?

回答4:

This will lead to a bit more code if you have a lot of ElementDefinitions you are worried about, but is probably the slickest you will get that doesn't involve is then as nonsense.

    public void DoSomething<G>(G generic)
        where G : ElementDefinition
    {
        DetailElement detail = generic as DetailElement;
        if (detail != null)
        {
            detail.DescEN = "Hello people";
        }
        else
        {
            //do other stuff
        }
    }

Another possible solution that I have used when I needed such information, in loo of a temporary object variable.

DetailElement detail = (DetailElement)(object)generic;

It works, but the as form is probably the best.

来源：https://stackoverflow.com/questions/183923/compiler-fails-converting-a-constrained-generic-type

标签

generics

casting

constraints