Friday, 18 August 2017

Covariance and Contravariance in Delegates

Delegates covariance and contravariance is a rather confusing topic and I'm not going to put any theory here, you can check any MSDN or stackoverflow response for that, I'll just put here a fast, personal reference. For an excellent approach to Variance in Programming languages, you should read this.
Short ago I talked about Converting from one delegate type to another different delegate type with the same signature. Covariance and contravariance in Delegates is a different topic, but we'll see that in one case it saves us having to do that conversion.

Since C# 2.0 covariance and contravariance applies to the rules that dictate that you can create a delegate of a certain type that points to a method of a certain return type and signature. We no longer need a perfect match between return types and the signature. You can read about it in Variance in Delegates.

What C# 4 brought to the table was covariance and contravariance between related generic delegates. Basically, now you have a relation between Func<Animal> and Func<Cat> and between Action<Cat> and Action<Animal>. It's explained in Variance in Generic and Non-Generic Delegates

I'll put some examples here for easy reference

Delegate Covariance (for return types)

If we have these custom delegate types and method:

  public delegate Animal CreateAnimalDelegate();
  public delegate Cat CreateCatDelegate();
  public static Cat CreateCat(){
   return new Cat();

Since C# 2.0 (one MSDN article mentions 3.0, it's wrong) we can do this, bind a delegate type (returning an Animal) to a method returning a more derived type (Cat):

CreateAnimalDelegate animalCreator = CreateCat;

If we are using generic delegates we can do the same (this is not related to the out keyword introduced in C# 4), here this continues to be delegate binding.

Func<Animal> animalCreatorFunc = CreateCat;

C# 4 brought something new, you can point a variable of a certain delegate type to an instance of a delegate of a different but related type. From MSDN

In .NET Framework 4 or later you can enable implicit conversion between delegates, so that generic delegates that have different types specified by generic type parameters can be assigned to each other, if the types are inherited from each other as required by variance.

//so thanks to C# 4 I can do this assignment of a different delegate type, there is no conversion it's just type compability
Func<Cat> catCreatorFunc = CreateCat;
Func<Animal> animalCreatorFunc = catCreatorFunc;

//so in C# 4 there is type compability, but not really inheritance ("is" works, but "IsSubclassOf" does not)
Console.WriteLine("catCreatorFunc " + ((catCreatorFunc is Func<Animal>)? "IS" : "IS NOT" ) + " Func<Animal>"); //IS 
Console.WriteLine("Func<Cat> " + ((typeof(Func<Cat>).IsSubclassOf(typeof(Func<Animal>)))? "IS" : "IS NOT" ) + " Func<Animal>"); //IS NOT!!!

As you see in the example I can point a Func<Animal> to a Func<Cat>, it's as if they were in an inheritance hierarchy, but it's not really the case, cause while the is operator will tell us that Func<Cat> is a Func<Animal>, the IsSubclassOf will tell us that no inheritance exists.

All in all Covariance for return types seems pretty natural, same as we can do Animal an = new Cat(); , we can do Func<Animal> fAn = new Func<Cat>...;

Delegate Contravariance (for arguments)

Delegate Contravariance seems a bit less natural, cause basically we can do: Action<Cat> aCat = new Action<Animal>.... So it seems we are reversing the way we use type compability (a Cat is an Animal for sure, but here we seem to say that an Animal is a Cat). If we think that this applies to parameters it makes total sense. We invoke aCat passing a Cat to it. aCat points now to a function that expects an Animal, so if it receives a Cat it will behave nicely.

I'm putting here the equivalent contravariant samples for the ones above

public delegate void ManageAnimalDelegate(Animal an);
public delegate void ManageCatDelegate(Cat cat);
public static void ManageAnimal(Animal an){

Bind a delegate type (expecting a Cat) to a method expecting a less derived type (Animal):

ManageCatDelegate catManager = ManageAnimal;

If we are using generic delegates we can do the same (this is not related to the out keyword introduced in C# 4), here this continues to be delegate binding.

Action<Cat> catManagerAction = ManageAnimal; //this one looks a bit odd cause we are sort of doing Cat = Animal;

And what was added in C# 4

Action<Animal> animalManagerAction = ManageAnimal;
Action<Cat> catManagerAction = animalManagerAction;

Console.WriteLine("animalManagerAction " + ((animalManagerAction is Action<Cat>) ? "IS" : "IS NOT" ) + " Action<Cat>"); //IS
Console.WriteLine("Action<Animal> " + ((typeof(Action<Animal>).IsSubclassOf(typeof(Action<Cat>)))? "IS" : "IS NOT" ) + " Action<Cat>"); //IS NOT!!!

To finish this article, I'll mention that while return type covariance applies to delegates, unfortunately (in C#) it does not apply to overriden methods in a derived class (Java has support for this since a long while). For contravariant arguments, again it applies only to delegates. The feature is not available for methods in hardly any language.
To my surprise, I learn that Eiffel supports Covariance in method arguments

No comments:

Post a Comment