Why does this generic constraint compile when it seems to have a circular reference

UPDATE: This question was the basis of my blog article on the 3rd of February 2011. Thanks for the great question!

---

This is legal, it is not circular, and it is fairly common. I personally dislike it.

The reasons I dislike it are:

1. It is excessively clever; as you’ve discovered, clever code is hard for people unfamiliar with the intricacies of the type system to intuitively understand.

2. It does not map well to my intuition of what a generic type “represents”. I like classes to represent categories of things, and generic classes to represent parameterized categories. It is clear to me that a “list of strings” and a “list of numbers” are both kinds of lists, differing only in the type of the thing in the list. It is much less clear to me what “a TextInput of T where T is a TextInput of T” is. Don’t make me think.

3. This pattern is frequently used in an attempt to enforce a constraint in the type system which is actually not enforcable in C#. Namely this one:

   abstract class Animal<T> where T : Animal<T>
   {
       public abstract void MakeFriends(IEnumerable<T> newFriends);
   }
   class Cat : Animal<Cat>
   {
       public override void MakeFriends(IEnumerable<Cat> newFriends) { ... }
   }
   

The idea here is “a subclass Cat of Animal can only make friends with other Cats.”

The problem is that the desired rule is not actually enforced:

class Tiger: Animal<Cat>
{
    public override void MakeFriends(IEnumerable<Cat> newFriends) { ... }
}

Now a Tiger can make friends with Cats, but not with Tigers.

To actually make this work in C# you’d need to do something like:

abstract class Animal 
{
    public abstract void MakeFriends(IEnumerable<THISTYPE> newFriends);
}

where “THISTYPE” is a magical new language feature that means “an overriding class is required to fill in its own type here”.

class Cat : Animal 
{
    public override void MakeFriends(IEnumerable<Cat> newFriends) {}
}

class Tiger: Animal
{
    // illegal!
    public override void MakeFriends(IEnumerable<Cat> newFriends) { ... }
}

Unfortunately, that’s not typesafe either:

Animal animal = new Cat();
animal.MakeFriends(new Animal[] {new Tiger()});

If the rule is “an animal can make friends with any of its kind” then an animal can make friends with animals. But a cat can only make friends with cats, not tigers! The stuff in the parameter positions has got to be valid contravariantly; in this hypothetical case we’d be requiring covariance, which isn’t going to work.

I seem to have digressed somewhat. Returning to the subject of this curiously recurring pattern: I try to only use this pattern for common, easily understood situations like the ones mentioned by other answers:

class SortedList<T> where T : IComparable<T>

That is, we need every T to be comparable to every other T if we have any hope of making a sorted list of them.

To actually be flagged as circular there has to be a bona-fide circularity in dependencies:

class C<T, U> where T : U where U : T

An interesting area of type theory (that at present the C# compiler handles poorly) is the area of non-circular but infinitary generic types. I have written an infinitary type detector but it did not make it into the C# 4 compiler and is not a high priority for possible hypothetical future versions of the compiler. If you’re interested in some examples of infinitary types, or some examples of where the C# cycle detector messes up, see my article on that:

https://ericlippert.com/2008/05/07/covariance-and-contravariance-part-11-to-infinity-but-not-beyond/