In the CLR via c# third edition there is an example that I cant seem to make sense of:
Invariant Meaning that that generic type parameter cannot be changed. I have shown only invariant generic type parameters so far in this chapter. n
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. n 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.
The author then goes on to give this example:
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
Here is where I run into the issue on the following page(292) he then goes on the say the opposite when using an interface.
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" });
In the second example he uses the out key word (IEnumerator<out T>
) and then calls it contravariant. Is this correct or am I missing something. Is there a difference defining a contravariant & covariant in an interface? I have been to Oreilly's website regarding this book and this is not listed.
Delegate.Combine
is fundamentally incompatible with variance. If a routine has an initially-null field of delegate typeAction<Cat>
, and it tries toCombine
it with anAction<Animal>
, the field of typeAction<Cat>
will hold a reference to anAction<Animal>
. If one then tries toCombine
that with anAction<Cat>
, the attempt will fail. For this reason, delegates types which may ever be used withCombine
should not be covariant nor contravariant. It's too bad delegate types don't define their ownCombine
methods, since... – supercatAction<Cat>.Combine
could have safely taken theAction<Animal>
and converted it to a typeAction<Cat>
, knowing that the result of such a conversion would only be used by code which would feed it aCat
. – supercat