Note It is recommended that you use the generic Action and Func delegates that come in Visual Studio .NET

Encoder Denso QR Bar Code in Visual Studio .NET Note It is recommended that you use the generic Action and Func delegates that come

predefined in the Framework Class Library (FCL) wherever possible . I describe these delegate types in the Enough with the Delegate Definitions Already (Generic Delegates) section of 17, Delegates .

Each of a delegate s generic type parameters can be marked as covariant or contravariant . This feature allows you to cast a variable of a generic delegate type to the same delegate type where the generic parameter types differ . A generic type parameter can be any one of the following:

Invariant Meaning that that generic type parameter cannot be changed . I have shown only invariant generic type parameters so far in this chapter . Contravariant Meaning that the generic type parameter can change from a class to a class derived from it . In C#, you indicate contravariant generic type parameters with the in keyword . Contravariant generic type parameters can appear only in input positions such as a method s argument . Covariant Meaning that the generic type argument can change from a class to one of its base classes . In C#, you indicate covariant generic type parameters with the out keyword . Covariant generic type parameters can appear only in output positions such as a method s return type .

For example, let s say that the following delegate type definition exists (which, by the way, it does):

public delegate TResult Func<in T, out TResult>(T arg);

Here, the generic type parameter T is marked with the in keyword, making it contravariant; and the generic type parameter TResult is marked with the out keyword, making it covariant . So now, if I have a variable declared as follows:

Func<Object, ArgumentException> fn1 = null;

I can cast it to another Func type, where the generic type parameters are different:

Func<String, Exception>fn2 = fn1;// No explicit cast is required here Exception e = fn2("");

What this is saying is that fn1 refers to a function that accepts an Object and returns an ArgumentException . The fn2 variable wants to refer to a method that takes a String and returns an Exception . Since you can pass a String to a method that wants an Object (because String is derived from Object), and since you can take the result of a method that returns an ArgumentException and treat it as an Exception (because Exception is a base class of ArgumentException), the code above compiles and is known at compile time to preserve type safety .

types . In other words, variance is not possible for value types because boxing would be required . In my opinion, this restriction is what makes these variance features not that useful . For example, if I have the following method:

voidProcessCollection(IEnumerable<Object> collection) { ... }

I can t call it passing in a reference to a List<DateTime> object since a reference conversion doesn t exist between the DateTime value type and Object even though DateTime is derived from Object . You solve this problem by declaring ProcessCollection as follows:

void ProcessCollection<T>(IEnumerable<T> collection) { ... }

Plus, the big benefit of ProcessCollection(IEnumerable<Object> collection) is that there is only one version of the JITted code . However, with ProcessCollection<T>(IEnumerable<T> collection), there is also only one version of the JITted code shared by all Ts that are reference types . You do get other versions of JITted code for Ts that are value types, but now you can at least call the method passing it a collection of value types . Also, variance is not allowed on a generic type parameter if an argument of that type is passed to a method using the out or ref keyword . For example, the line of code below causes the compiler to generate the following error message: "Invalid variance: The type parameter

'T' must be invariantly valid on 'SomeDelegate<T>.Invoke(ref T)'. 'T' is contravariant."

delegate void SomeDelegate<in T>(ref T t);

When using delegates that take generic arguments and return values, it is recommended to always specify the in and out keywords for contravariance and covariance whenever possible, as doing this has no ill effects and enables your delegate to be used in more scenarios . Like delegates, an interface with generic type parameters can have its type parameters be contravariant or covariant . Here is an example of an interface with a contravariant generic type parameter:

public interface IEnumerator<out T> : IEnumerator { Boolean MoveNext(); T Current { get; } }

Since T is contravariant, it is possible to have the following code compile and run successfully:

// This method accepts an IEnumerable of any reference type Int32 Count(IEnumerable<Object> collection) { ... } ... // The call below passes an IEnumerable<String> to Count Int32 c = Count(new[] { "Grant" });