4826.7.1 Satisfying constraints

C# LANGUAGE SPECIFICATION

1• If the constraint is a class type, an interface type, or a type parameter, let C represent that constraint with

2the supplied type arguments substituted for any type parameters that appear in the constraint. To satisfy

3the constraint, it shall be the case that type A is convertible to type C by one of the following:

4o An identity conversion (§13.1.1)

5o An implicit reference conversion (§13.1.4)

6o A boxing conversion (§13.1.5)

7o An implicit conversion from a type parameter A to C (§26.7.4).

8• If the constraint is the reference type constraint, the type A must satisfy one of the following:

9o A is an interface type, class type, delegate type or array type. [Note: Note that System.ValueType

10and System.Enum are reference types so satisfy this constraint. end note]

11o A is a type parameter that is known to be a reference type (§26.7).

12• If the constraint is the value type constraint, the type A must satisfy one of the following:

13o A is a struct type or enum type. [Note: Note that System.ValueType and System.Enum are

14reference types so do not satisfy this constraint. end note]

15o A is a type parameter having the value type constraint (§26.7).

16• If the constraint is the constructor constraint new(), the type argument A shall not be abstract and

17shall have a public parameterless constructor. This is satisfied if one of the following is true:

18o A is a value type, since all value types have a public default constructor (§11.1.2).

19o A is a type parameter having the value type constraint (§26.7).

20o A is a class that is not abstract, A contains an explicitly declared public constructor with no

21parameters.

22o A is not abstract and has a default constructor (§17.10.4).

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

24type arguments.

25Since type parameters are not inherited, constraints are never inherited either. [Example: In the code below,

26D needs to specify the constraint on its type parameter T, so that T satisfies the constraint imposed by the

27base class B<T>. In contrast, class E need not specify a constraint, because List<T> implements

28IEnumerable for any T.

29class B<T> where T: IEnumerable {…}

30class D<T>: B<T> where T: IEnumerable {…}

31class E<T>: B<List<T>> {…}

32end example]

3326.7.2 Member lookup on type parameters

34The results of member lookup in a type given by a type parameter T depends on the constraints, if any,

35specified for T. If T has no class-type, interface-type or type-parameter constraints, then member lookup on

36T returns the same set of members as member lookup on object. Otherwise, the first stage of member

37lookup (§14.3) considers all the members in the effective base class of T and all the members in each

38interface in the effective interface set of T. After performing the first stage of member lookup for each of

39theses types, the results are combined, and then hidden members are removed from the combined results.

40Before the advent of generics, member lookup always returned either a set of members declared solely in

41classes, or a set of members declared solely in interfaces and possibly the type object. Member lookup on

42type parameters changes this somewhat. When a type parameter has both an effective base class other than

43object and a non-empty effective interface set, member lookup can return a set of members, some of which

420

C# LANGUAGE SPECIFICATION

1struct Counter: ICounter

2{

9}

10}

11class Program

12{

23}

24}

25The first call to Increment modifies the value in the variable x. This is not equivalent to the second call to

26Increment, which modifies the value in a boxed copy of x. Thus, the output of the program is:

270

281

291

30end example]

3126.7.4 Conversions involving type parameters

32The conversions that are allowed on a type parameter T depend on the constraints specified for T and are

33detailed in §13.

34The conversion rules do not permit a direct explicit conversion from an unconstrained type parameter to an

35arbitrary non-interface type, which might be surprising. The reason for this rule is to prevent confusion and

36make the semantics of such conversions clear. [Example: Consider the following declaration:

37class X<T>

38{

41}

42}

43If the direct explicit conversion of t to long were permitted, one might easily expect that X<int>.F(7)

44would return 7L. However, it would not, because the standard numeric conversions are only considered

45when the types are known to be numeric at compile time. In order to make the semantics clear, the above

46example should be written:

47class X<T>

48{

51}

52}

53This code will now compile but executing X<int>.F(7) would then throw an exception at runtime, since a

54boxed int cannot be converted directly to a long.

55end example]

422