Today’s episode is presented as a dialogue:

Why are generic constraints not inherited?

Members are inherited. Generic constraints are not members of a type.

But generic constraints are inherited on generic methods, right?

That’s true, though what is inherited is the method and the constraint comes along with it. What is a bit odd is: generic constraints on methods are invisibly inherited when overriding, which has always vexed me. My preferred design would have been to require that the constraint be re-stated. That is, when you say:

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

U in D.M<U> is still constrained to struct, but it is actually illegal in C# to re-state that fact redundantly! This is a bit of a misfeature in my opinion; it works against code clarity for the reader. Particularly since the base class might not even be in source code; it might be in a different assembly entirely.

(Note that I’m emphasizing here that there is no requirement that the type parameters be named the same. Similarly there is no requirement that the formal parameters be named the same either, but it is a good idea to do so. We’ll come back to this point in a moment.)

So why then aren’t generic type constraints on type-level type parameters invisibly inherited in the same way?

I’m not following you. Can you give an example?

Sure!

class E<T> where T : struct { } 
// Illegal because U is not known to be struct
class F<U> : E<U> { }

Why is it that in the method overriding example the type constraint is invisibly inherited, but here the type constraint must be re-stated?

Ah, now I see what you’re asking.

These situations are similar but different. In the method overloading situation the substitution of U for T is essentially simply renaming the type parameter. In the subclass, U is a brand new type, and that type is being substituted for T via generic construction. Remember, you could have said class F : E<int> { }, but could not have said public override void M<int>() { }! These are similar-looking substitutions but are actually quite different logically.

OK, then let me re-phrase my question in the form of a feature request. I don’t want constraints to be inherited per se. Rather, in my example I would like all the constraints required to be placed on U to be automatically deduced and invisibly added.

That’s an interesting kind of inference that could be added to C#; were I still on the language design team and had this feature pitched, here are the objections I would raise.

The example given yields a trivial solution; obviously U must have a value type constraint placed on it in order to satisfy its usage in E<U>. So let’s start looking at some non-obvious examples:

class G<T, U> where T : X where U : Y {}
class H<V> : G<V, V> {}

Notice that I haven’t said whether X and Y are classes or interfaces. Should we deduce that V must be constrained to both X and Y? Suppose X is a subclass of Y – we would normally not allow

class H<V> : G<V, V> where V : Tiger where V : Animal {}

but presumably you’d like that to be simplified to

class H<V>: G<V, V> where V : Tiger {}

which adds cost to the feature.

Suppose the compiler can deduce that there is no type that satisfies the inferred constraints — perhaps in this case X and Y are Animal and Fruit — should the compiler be required to produce a warning? An error? Again, this is adding a lot of cost to the feature. Detecting error cases is tricky and writing error messages that the user can understand is also tricky.

But again, we’ve got a scenario here where the deductions are very easy to make, it’s just what to do with them once their made that is in question. What if the deductions themselves are hard to make? Here, let me just whip up some types off the top of my head:

class Banana<T> where T : Coffee<T> {}
class Coffee<U> : Banana<Giraffe<U>> where U : INewspaper<Coffee<U>> {}
class Giraffe<V> : Coffee<Banana<V>> where V : IVehicle<V> {}

Every type has constraints already. Are we now required by the feature to add more constraints? T is required to be Coffee<T>. Banana<T> is constructed with type argument Giraffe<U>, so Giraffe<U> is required to be Coffee<U>, but it actually inherits from Coffee<Banana<U>>. Should we then deduce that U is required to be Banana<U>? Wait a minute, is that deduction correct? Or is that deduction only valid if classes are covariant — which they are not in C#? Now I’m confused and we’ve only just started. And that brings up a good question: what if those interfaces are covariant? Or contravariant? How does that change the analysis?

And you see how this goes. Any time you step away from the most trivial cases, the difficulty of the inference just explodes. There are techniques for making inferences like this; they are a lot of work for very little gain.

My final criticism of the feature proposal is that it is insufficiently general. The feature request is to make a certain kind of inference – a type constraint – based on a certain kind of evidence – a type substitution in a generic type found in the list of base types. Well what is so special about that list of base types? Surely I should be able to make this inference based on any substitution, not just substitutions in the base type. If I say

class Frob<T> where T : struct {}
class Blob<U> { Frob<U> frobu; }

then surely I can deduce that U must also be constrained to struct from the field declaration. What’s so special about the base type? And if there’s nothing special about the base type, where does it stop? The logical extension of the feature requires a deep analysis of the whole program, which seems like far too much work for so little savings.

No, the whole thing is too complicated, and the whole thing is putting the cart before the horse. When you construct a generic type, you are required to prove to the compiler that the type you’ve supplied meets the constraints. In the case of generic type parameters that are themselves supplied as type arguments, you provide that proof by constraining them explicitly, not relying on the compiler to make a guess at what you meant.