What exactly is a “Special Class”?

Question

After failing to get something like the following to compile:

public class Gen where T : System.Array
{
}

with the error

Answer 1

From the Roslyn source code, it looks like a list of hardcoded types:

switch (type.SpecialType)
{
    case SpecialType.System_Object:
    case SpecialType.System_ValueType:
    case SpecialType.System_Enum:
    case SpecialType.System_Delegate:
    case SpecialType.System_MulticastDelegate:
    case SpecialType.System_Array:
        // "Constraint cannot be special class '{0}'"
        Error(diagnostics, ErrorCode.ERR_SpecialTypeAsBound, syntax, type);
        return false;
}

Source: Binder_Constraints.cs IsValidConstraintType
I've found it using a GitHub search: "A constraint cannot be special class"

Answer 2

There are certain classes in the Framework which effectively pass on special characteristics to all types derived from them but do not possess those characteristics themselves. The CLR itself imposes no prohibition against using those classes as constraints, but generic types constrained to them would not acquire the non-inherited characteristics the way concrete types would. The creators of C# decided that because such behavior might confuse some people, and they failed to see any usefulness to it, they should prohibit such constraints rather than allow them to behave as they do in the CLR.

If, for example, one were allowed to write: void CopyArray<T>(T dest, T source, int start, int count); one would be able to pass dest and source to methods which expect an argument of type System.Array; further, one would get compile-time validation that dest and source were the compatible array types, but one would not be able to access elements of the array using the [] operator.

The inability to use Array as a constraint is mostly pretty easy to work around, since void CopyArray<T>(T[] dest, T[] source, int start, int count) will work in almost all situation where the former method would work. It does, however, have a weakness: the former method would work in the scenario that one or both of the arguments was of type System.Array while rejecting cases where the arguments are incompatible array types; adding an overload where both arguments were of type System.Array would make the code accept the additional cases it should accept, but also make it erroneously accept cases it should not.

I find the decision to outlaw most of the special constraints irksome. The only one which would have zero semantic meaning would be System.Object [since if that were legal as a constraint, anything would satisfy it]. System.ValueType probably wouldn't be very useful, since references of type ValueType don't really have much in common with value types, but it might plausibly have some value in cases involving Reflection. Both System.Enum and System.Delegate would have some real uses, but since the creators of C# didn't think of them they're outlawed for no good reason.

Answer 3

I found a Jon Skeet comment from 2008 on a similar question: Why is the System.Enum constraint not supported.

I know this is a bit off topic, but he asked Eric Lippert (the C# team) about it and they provided this answer:

First off, your conjecture is correct; the restrictions on constraints are by and large artefacts of the language, not so much the CLR. (Were we to do these features there would be a few minor things we'd like to change in the CLR regarding how enumerable types are specified, but mostly this would be language work.)

Second, I would personally love to have delegate constraints, enum constraints, and the ability to specify constraints that are illegal today because the compiler is trying to save you from yourself. (That is, making sealed types legal as constraints, and so on.)

However, due to scheduling restrictions, we will likely not be able to get these features into the next version of the language.

Answer 4

According to MSDN it's a static list of classes:

Compiler Error CS0702

Constraint cannot be special class 'identifier' The following types may not be used as constraints:

• System.Object
• System.Array
• System.Delegate
• System.Enum
• System.ValueType.

Answer 5

The following can be found in CLR via C# 4th Edition:

Primary Constraints

A type parameter can specify zero primary constraints or one primary constraint. A primary constraint can be a reference type that identifies a class that is not sealed. You cannot specify one of the following special reference types: System.Object, System.Array, System.Delegate, System.MulticastDelegate, System.ValueType, System.Enum, or System.Void. When specifying a reference type constraint, you are promising the compiler that a specified type argument will either be of the same type or of a type derived from the constraint type.

Answer 6

I don't think, that there exists any official definition of "special classes"/"special types".

You may think about them a a types, which can't be used with semantic of "regular" types:

• you can't instantiate them directly;
• you can't inherit custom type from them directly;
• there is some compiler magic to work with them (optionally);
• the direct usage of their instances at least useless (optionally; imagine, that you've created generic above, what generic code are you going to write?)

P.S. I'd add System.Void to the list.