Why Aren't Generic Type Constraints Inheritable/Hierarchically Enforced

Why aren't generic type constraints inheritable/hierarchically enforced

ANOTHER UPDATE:

This question was the subject of my blog in July 2013. Thanks for the great question!

UPDATE:

I've given this some more thought and I think the problem is that you don't want inheritance at all. Rather, what you want is for all constraints that must be placed on a type parameter in order for that type parameter to be used as a type argument in another type to be automatically deduced and invisibly added to the declaration of the type parameter. Yes?

Some simplified examples:

class B<T> where T:C {}
class D<U> : B<U> {}

U is a type parameter that is used in a context where it must be C. Therefore in your opinion the compiler should deduce that and automatically put a constraint of C on U.

What about this?

class B<T, U> where T : X where U : Y {}
class D<V> : B<V, V> {}

Now V is a type parameter used in a context where it must be both X and Y. Therefore in your opinion the compiler should deduce that and automatically put a constraint of X and Y on V. Yes?

What about this?

class B<T> where T : C<T> {}
class C<U> : B<D<U>> where U : IY<C<U>> {}
class D<V> : C<B<V>> where V : IZ<V> {}

I just made that up, but I assure you that it is a perfectly legal type hierarchy. Please describe a clear and consistent rule that does not go into infinite loops for determining what all the constraints are on T, U and V. Don't forget to handle the cases where type parameters are known to be reference types and the interface constraints have covariance or contravariance annotations! Also, the algorithm must have the property that it gives exactly the same results no matter what order B, C and D appear in source code.

If inference of constraints is the feature you want then the compiler has to be able to handle cases like this and give clear error messages when it cannot.

What is so special about base types? Why not actually implement the feature all the way?

class B<T> where T : X {}
class D<V> { B<V> bv; }

V is a type parameter used in a context where it must be convertible to X; therefore the compiler should deduce this fact and put a constraint of X on V. Yes? Or no?

Why are fields special? What about this:

class B<T> { static public void M<U>(ref U u) where U : T {} }
class D<V> : B<int> { static V v; static public void Q() { M(ref v); } }

V is a type parameter used in a context where it can only be int. Therefore the C# compiler should deduce this fact and automatically put a constraint of int on V.

Yes? No?

You see where this is going? Where does it stop? In order to implement your desired feature properly the compiler must do whole-program analysis.

The compiler does not do this level of analysis because that is putting the cart before the horse. When you construct a generic, you are required to prove to the compiler that you've satisfied the constraint. It's not the compiler's job to figure out what you meant to say and work out what further set of constraints satisfy the original constraint.

For similar reasons, the compiler also does not attempt to automatically infer variance annotations in interfaces on your behalf. See my article on that subject for details.

http://blogs.msdn.com/b/ericlippert/archive/2007/10/29/covariance-and-contravariance-in-c-part-seven-why-do-we-need-a-syntax-at-all.aspx

---

Original answer:

I would like to know why aren't generic type constraints inheritable?

Only members are inherited. A constraint is not a member.

if my inherited class inherits from base class and passes over its generic type which has a constraint on the base class it automatically means that generic type in inherited class should have the same constraint without explicitly defining it. Shouldn't it?

You're just asserting how something should be, without providing any explanation of why it should be that way. Explain to us why you believe that the world should be that way; what are the benefits and what are the drawbacks and what are the costs?

Am I doing something wrong, understanding it wrong or is it really that generic type constraint aren't inheritable?

Generic constraints are not inherited.

If the latter is true, why in the world is that?

Features are "not implemented" by default. We don't have to provide a reason why a feature is not implemented! Every feature is not implemented until someone spends the money to implement it.

Now, I hasten to note that generic type constraints are inherited on methods. Methods are members, members are inherited, and the constraint is a part of the method (though not part of its signature). So the constraint comes along with the method when it is inherited. When you say:

class B<T> 
{
    public virtual void M<U>() where U : T {}
}

class D<V> : B<IEnumerable<V>>
{
    public override void M<U>() {}
}

Then D<V>.M<U> inherits the constraint and substitutes IEnumerable<V> for T; thus the constraint is that U must be convertible to IEnumerable<V>. Note that C# does not allow you to restate the constraint. This is in my opinion a misfeature; I would like to be able to restate the constraint for clarity.

But D does not inherit any kind of constraint on T from B; I don't understand how it possibly could. M is a member of B, and is inherited by D along with its constraint. But T is not a member of B in the first place, so what is there to inherit?

I'm really not understanding at all what feature it is that you want here. Can you explain with more details?

Why is some ordering enforced in generic parameter constraints?

There's no particular reason why that order was chosen. The chosen order goes from more general to more specific, which I suppose is a reasonably nice property.

As for the question "why require an order at all?", it's simply easier on the implementation and testing teams to have a clear, unambiguous order imposed by the language. We could allow the constraints to come in any order, but what does that buy us?

The longer I work on languages the more I'm of the opinion that every time you give the user a choice, you give them an opportunity to make a bad choice. A basic design principle of C# is that we tell you when things look wrong and force you to make them right -- which is not a basic design principle of, say, JavaScript. Its basic design principle is "muddle on through and try to do what the user meant". By placing more restrictions on what is correct syntax in C# we can better ensure that the intended semantics are expressed well in the program.

For example, if I were designing a C#-like language today there is no way that I would have ambiguous syntaxes like:

class C : X , Y

or

... where T : X, Y

Y is clearly intended to be an interface. Is X? We can't tell syntactically whether X was intended to be an interface or a class. Suffice to say this ambiguity greatly complicates things like detecting cycles in base types vs interfaces and so on. It'd be much easier on all concerned if it were more verbose, as it is in VB.

Why sealed classes are not allowed to be generic type constraints?

Because then there's no point in it being generic. T could only be Base, so you might as well make it a non-generic type to start with.

Why would you want Derived to be generic here? Why would you want a type called Base (implying that it should be a base type) to be sealed?

How do you access a common property of generic type inside a method in C# (using constraints?)

First you must create a hierarchy of objects:

public class BaseClass
{
    public object CommonProperty { get; set; }
}

public class Class1 : BaseClass
{
}

public class Class2 : BaseClass
{
}

Then you can use the where generic type constraint to specify the generic type:

public Task DoSomething<T>(T class) where T : BaseClass
{
    // do stuff
    var commonProperty = class.commonProperty 
    // do stuff
}

Inheritance on a constrained generic type parameter

Because you can't. Generics are not templates. You shouldn't think about them like C++ templates and expect the same behavior. They are fundamentally different concepts.

The C# specification explicitly prohibits usage of type parameters as base class:

C# 3.0 Language Specification: Type Parameters (§4.5)

A type parameter cannot be used directly to declare a base class (§10.2.4) or interface (§13.1.3).

Update:

I understand what you want to do and its use. This is a traditional use case of C++ templates. Specifically, if this was possible to do using C# generics, things like Moq library could benefit from it. The problem is, C++ templates are compile time "find and replace" constructs while C# generics are a run time thing.

To demonstrate this fact, for this class:

class Test<T> where T : class {
    // whatever contents it might have...
} 

only a single IL will be emitted at compile time and at run time, the JIT compiler would generate a single native code for all reference-type type parameters. This is not like C++ templates at all, where native code would be emitted for every T separately (it's subject to optimization but conceptually, they are completely separate pieces of code).

Is it pointless to have both class and new() constraints in a generic class?

new() doesn't imply a reference type, so: No, class is not redundant when using new().

The following code demonstrates that:

void Main()
{
    new MyParanoidClass<S>();
}

struct S {}

class MyParanoidClass<T> where T : new()
{
    //content
}

This code compiles, proving that new() doesn't care if you use a reference or a value type.

Pass Generic Type up the Inheritance Tree

I get your code to compile if you add the new() constraint to Contact<T>:

public abstract class Contact<T> : DBObject<T> 
    where T : Contact<T>, new()
{ 
    //field and methods ommitted...
} 

This is necessary since generic constraints aren't inherited.

---

Related Topics