C# generics type constraint

Question

Should't this be valid C# code?

class A<T> where T : class {

    public void DoWork<K>() where K : T {

        var b = new B<K>(); // <- compile time error
    }
}

class B<U> where U : class {

}

The compiler spits this error:

error CS0452: The type 'K' must be a reference type in order to use it as parameter 'U' in the generic type or method 'ConsoleApplication1.B'

Shouldn't the compiler be able to figure out that K is constraint to be of type T or derived from T so it should obviously be a reference type (T is constrained to be a reference type)?

It's just another of those 'why can't the compiler figure this out for me...' questions. Bottom line is because compiler developer's time costs money and Microsoft has a finite amount of it to play with. There will always be edge cases no matter how much the compiler can do, at these edges it needs you to step in and help. — James Gaunt, Feb 18 '11 at 13:53
well, probably compiler development is not cheap. I was wondering if this behaviour is desired or has somehow slipped through without being noticed. — xenry, Feb 18 '11 at 14:14
@James: In this case, the compiler is doing what the spec says it should do. — Jeff Yates, Feb 18 '11 at 14:20
@Jeff - of course it is. I'm not saying this is a bug or an oversight. The spec and the compiler are written together. There isn't one team writing the spec and another team saying 'we haven't got time to do that'. There is one team saying 'this is what we have time/money to do' and then writing the compiler and the spec to reflect that. — James Gaunt, Feb 18 '11 at 14:30
@James: I would expect the spec is written first and with due consideration to not only the features to be provided by the language but also the time and budgetary constraints. That said, regardless of the compiler implementation, it is clear to me that having the compiler infer this information is a high cost, low return thing to implement so it was probably easy to pass over. I'm sure one of the C# gurus could shed more light on that. — Jeff Yates, Feb 18 '11 at 14:48

score 8 · Answer 1 · answered Mar 26 '11 at 23:47

My earlier answer was incorrect; I've deleted it. Thanks to user configurator who pointed out my error.

Shouldn't the compiler be able to figure out that K is constraint to be of type T or derived from T so it should obviously be a reference type (T is constrained to be a reference type)?

No.

K is constrained to be of type T or a type derived from T. T is constrained to be a reference type. This does not imply that K is a reference type. Viz: object is a reference type, and int is a type derived from object. If T is object then K can be int, which is not a reference type.

score 7 · Accepted Answer · edited May 23 '17 at 12:11

The constraints are applied when the type parameter is specified. A type has not been specified for K even though K is being specified for U. As U requires its type to be a reference type, the compiler is looking to confirm that K is indeed a reference type, but it cannot. Therefore, you need to explicitly state that it will be.

The specification states in section 4.4.4:

For each where clause, the type argument A that corresponds to the named type parameter is checked against each constraint...

and later:

A compile-time error occurs if one or more of a type parameter’s constraints are not satisfied by the given type arguments.

Since type parameters are not inherited, constraints are never inherited either.

This last point indicates that K will not inherit the constraints from T.

Update
While my conclusions appear correct, my evidence is a little shaky as was clarified in a now deleted response from Eric Lippert's response. There, Eric stated that the correct part of the specification is:

A type parameter is known to be a reference type if it has the reference type constraint or its effective base class is not object or System.ValueType.

thanks, but I think your first paragraph is not clear enough or you have scrambled T, K, U. If you can correct it for future readers =) — xenry, Feb 18 '11 at 14:19
@xenry: You're right. I had T and U mixed up. Corrected. Thanks! — Jeff Yates, Feb 18 '11 at 14:22
it appears Eric Lippert has deleted the answer you are linking to. — Randy Levy, Mar 27 '11 at 05:47
@Tuzo: Yes, it would appear so. I'll see if I can incorporate the gist of his response. — Jeff Yates, Mar 27 '11 at 20:05

score 3 · Answer 3 · answered Feb 18 '11 at 13:50

Constraints don't cascade in this manner. Each generic signature has its own unique constraints that are evaluated independently of any sub-constraints that may be implied. You will need to make the class declaration on K as well as T and U even though it is already implied with T.

RQDQ · Answer 4 · 2011-02-18T13:52:37.800

2

Try this:

class A<T> where T : class
{
    public void DoWork<K>() where K : class, T 
    {
        var b = new B<K>(); // <- compile time error
    }
}

class B<U> where U : class
{
}

Unfortunately, it looks like the compiler isn't quite bright enough to infer. however, if you add some more constraints for K, you should be good to go.

edited Feb 18 '11 at 13:52

answered Feb 18 '11 at 13:44

RQDQ

15,461
2
32
59

I think this missed the point. It only compiles because you removed the class constraint on U. The compiler error on the indicated line isn't caused by the lack of new(), as it is B that is being instantiated, and we know that B is class with a parameterless constructor. – James Gaunt Feb 18 '11 at 13:49
Good point - I reworked my answer to incorporate your feedback. – RQDQ Feb 18 '11 at 13:53
It's not about the compiler being "bright enough" - the compiler is satisfying the specification that states "constraints are never inherited". – Jeff Yates Feb 18 '11 at 14:00
Two kind of entity are associated with each defined value type--one of which behaves as a class which inherits `System.ValueType`, and one of which behaves as a value type and doesn't inherit from anything; an implicit widening conversion is done from the latter to the former, and narrowing conversion can be done the other way. Unfortunately, there's no way to specify that a storage location should hold a reference to first kind of entity. If a type derives from System.ValueType, any storage location declared to be that type will behave like the value-type which doesn't derive from anything. – supercat Jan 25 '12 at 17:38

Nathan Craddock · Answer 5 · 2011-02-18T13:52:54.337

1

I think you need to specify that K : class and T.

class A<T> where T : class {

    public void DoWork<K>() where K : class, T {

        var b = new B<K>(); // <- compile time error
    }
}

class B<U> where U : class {

}

edited Feb 18 '11 at 13:52

answered Feb 18 '11 at 13:47

Nathan Craddock

690
4
15

Sebastien · Answer 6 · 2011-02-18T13:58:17.843

0

You should do this :

class A<T> where T : class
{

    public void DoWork<K>() where K: class, T
    {

        var b = new B<K>(); // <- compile time error
    }
}

class B<U> where U : class
{

}

edit : if you don't specify K as being a class and have a parameterless constructor, you'll compile-time errors : type U must be a ref type, and needs to have a parameterless constructor

edited Feb 18 '11 at 13:58

answered Feb 18 '11 at 13:50

Sebastien

80
1
7

C# generics type constraint

6 Answers6

Linked