Disclaimer: Theoretical Question

The new constraint specifies that any type argument in a generic class declarat开发者_JAVA技巧ion must have a public parameterless constructor.

Source: http://msdn.microsoft.com/en-us/library/sd2w2ew5(v=vs.80).aspx

What if I wanted my generic class to have a protected parameterless constructor instead? For instance, if I want to write a Singleton class which I "attach" to other classes to make them Singletons, I don't want the derived classes to be instantiable - everything should go through the .Instance property.

internal class Singleton<T> where T : new()
{
    public static T Instance { get; private set; }

    static Singleton()
    {
        Singleton<T>.Instance = new T();
    }
}

internal class OnlyOneOfMe : Singleton<OnlyOneOfMe>
{
    protected OnlyOneOfMe()
    {
    }
}

This way, Singleton<T> is able to create the only instance of the OnlyOneOfMe class, but nothing else can (unless it is a subclass).

"What if a generic parent class could access the generic type's protected members?"

Because that is the definition of the constraint. It's a bit like asking why does T : class require that T be a reference type. It's true by definition.

Additionally, if it weren't a public constructor, what would be the point of the constraint? The class receiving the type parameter T wouldn't be able to call the constructor if it weren't public.

You can call a protected constructor using reflection. However this should raise warning signs that you are doing something you are not supposed to. In most cases, you should be able to avoid a singleton and use dependency injection instead. If that doesn't work either, you can use something like the ambient context pattern (see my answer here).

.NET would not know that you don't want to accept

class OnlyOneOfMe : Singleton<Other>

as a valid class. Since it is actually valid it will try to make the class and needs a public Other constructor.

If the constructor were protected, Singleton wouldn't be able to call it.

And I'd avoid implementing the singleton pattern like that anyway, even if I could. It's messy - what if you wanted a singleton class that inherits from an abstract one?