Generic type constraint: How do I create an instance of the class described in this C# documentation

Question

where (generic type constraint) (C# Reference)

The relevant text from the document cited above is:

For example, you can declare a generic class, MyGenericClass, such that the type parameter T implements the IComparable<T> interface:

Here is MyGenericClass, copied verbatim from documentation cited above:

public class AGenericClass<T> where T : IComparable<T> { }

Here is a small console app shows my attempts to create the instance:

class Program
{
    static void Main(string[] args)
    {
        AGenericClass<MyComparable<string>> stringComparer = new AGenericClass<MyComparable<string>>(); // does not build


        AGenericClass<MyStringComparable> stringComparer2 = new AGenericClass<MyStringComparable>(); // does not build
    }
}


public class MyStringComparable : IComparable<string>
{
    public int CompareTo(string other) => throw new NotImplementedException();
}

public class MyComparable<T> : IComparable<T>
{
    public int CompareTo(T other) => throw new NotImplementedException();
}

// verbatim from documentation cited above
public class AGenericClass<T> where T : IComparable<T> { }  

For clarity my question is "How do I create an instance of AGenericClass as it is defined in the cited C# documentation". Please note my question relates to the specific example cited above, not other related questions such as this one and this one.

I'm obviously very confused on how type parameters work. I hope by answering this question I will become enlightened as it closely resembles the business problem I'm trying to solve.

Also my question has nothing to do with IComparable<T> or comparing objects - that just happens to be the interface in the example code.

Edit: Additional code provided based on reply from @CoolBots. This code provides a more realistic example and shows an interface that is intended to operate on a single object:

public class Program2
{

    public Program2()
    {
        Selector<Selectable<string>, string> stringSelector = new Selector<Selectable<string>, string>();
    }
}

public interface ISelectable<T>
{
    bool IsSelected { get; set; }
    T Item { get; set; }
}

public class Selectable<T> : ISelectable<T>
{
    public bool IsSelected { get; set; }
    public T Item { get; set; }
}

public class Selector<T, TData> where T:ISelectable<TData>
{
}

Answer 1

In your specific example, the generic parameter T in AGenericClass<T>, and the corresponding constraint, where T: IComparable<T> specify that the generic parameter T must implement IComparable<T> interface (which is not important to your question, but important to understanding what's going on, since this interface itself is generic). Note that T in IComparable<T> is the same T as in AGenericClass<T> - that is, you're restricting to a type that implements IComparable<T> of itself - a string is a great example, because it is IComparable<string> However, your MyStringComparable is not an IComparable<MyStringComparable> - it is an IComparable<string>, which fails the generic type constraint on AGenericClass<T>, as defined.

The solution here is to use 2 generic parameters - one for container, and one for the type contained:

class AGenericClass<TContainer, TData> where TContainer: IComparable<TData> { }

Instantiation is as follows:

var stringComparer = new AGenericClass<MyComparable<string>, string>();

var stringComparer2 = new AGenericClass<MyStringComparable, string>();

EDIT, based on your updated question and comments:

If you really want to get rid of the second generic parameter, something's gotta give - for instance, we can lose the ability to specify a container, making it a pass-through, similar to System.Collections.Generic.LinkedList<T>'s implementation - LinkedListNode<T> is a pass-through container, which is known to the LinkedList<T> class, and cannot be swapped out for a different kind of container:

public class Selector<T> //no constraint at all
{
   private Selectable<T> container; //the container is always Selectable<T>

   public Selector(T item)
      => container = new Selectable<T>() { Item = item };
}

Usage is simpler:

var selector = new Selector<string>("some data"); // no need to pass Selectable<string> here

However, you are now stuck with the Selectable<T> as the container - you can't make a BetterSelectable<T> and use it as the container interchangeably. Basically, it comes down to your use case - do you need 2 variables - a "container" and a "data contained", or are you ok with only one - just the data contained. In the former case, you must have 2 generic parameters (because you have 2 variables); in the latter case, you only need 1 generic parameter (because you have 1 variable, and one constant, namely the container).

Answer 2

For clarity my question is "How do I create an instance of AGenericClass as it is defined in the cited C# documentation"

By providing a type for the type parameter T that fulfills the constraint T : IComparable<T>. In your code example:

static void Main(string[] args)
{
    AGenericClass<MyComparable<string>> stringComparer = new AGenericClass<MyComparable<string>>(); // does not build


    AGenericClass<MyStringComparable> stringComparer2 = new AGenericClass<MyStringComparable>(); // does not build
}

You get compile-time errors because neither of the types you've provided satisfy that constraint. The way to fix the errors is to provide a type that does satisfy the constraint.

There are lots of types that already do satisfy the constraint. For example, int or any other primitive numeric type would. But presumably your question really is meant to be worded something more like this:

For clarity my question is "How do I create an instance of AGenericClass as it is defined in the cited C# documentation, using a user-defined type of my own as the type parameter"

The answer is still the same: satisfy the constraint in your user-defined type. So, why don't the types you already have do that? Let's see...

Here are your types:

public class MyStringComparable : IComparable<string>
{
    public int CompareTo(string other) => throw new NotImplementedException();
}

public class MyComparable<T> : IComparable<T>
{
    public int CompareTo(T other) => throw new NotImplementedException();
}

Let's test them one at a time. Let's suppose we set T to MyStringComparable. To satisfy the constraint, that type would need to implement IComparable<T> where T is the type you've provided as the type parameter. Since you set T to MyStringComparable, then MyStringComparable needs to implement IComparable<MyStringComparable>.

Does it? No, it does not. It implements IComparable<T> for some other type parameter T, namely string.

You would need something like this, in order to satisfy the constraint:

public class MyStringComparable : IComparable<MyStringComparable>
{
    public int CompareTo(MyStringComparable other) => throw new NotImplementedException();
}

Okay, what about the second one. Do the same test, using MyComparable<T> as the type parameter. Of course, you need to provide a type parameter for that class, since it's generic. In your example, you use string as the type parameter, so it's MyComparable<string>.

According to the constraint, the type parameter MyComparable<string> needs to implement IComparable<MyComparable<string>>. Does it? No, it does not. The MyComparable<string> class only implements IComparable<string>. Again, this is the wrong constraint.

A class that would implement the correct constraint would look more like this:

public class MyComparable<T> : IComparable<MyComparable<T>>
{
    public int CompareTo(MyComparable<T> other) => throw new NotImplementedException();
}

Generic type constraints can be tricky to deal with. Another area that people often get tangled up in is where trying to inherit or otherwise use an existing type parameter that has a constraint, forgetting that they need to satisfy the constraint in that context. Often this is done by repeating the constraint in their own generic class or method.

I'll also note with respect to this text in your question:

Also my question has nothing to do with IComparable or comparing objects - that just happens to be the interface in the example code.

Actually, your question has at least a moderate something to do with IComparable<T>, because it's often used in this sort of recursive way that trips people up. You wouldn't have run into the same problem with a more conventional scenario.

The scenario you've run into is the C# variation of C++'s "Curiously Recurring Template Pattern". Eric Lippert's written a useful article on the topic, which you might like to read as you explore and learn about generic type parameters and their constraints.