Nota: Este post ha sido importado de mi blog de geeks.ms. Es posible que algo no se vea del todo "correctamente". En cualquier caso puedes acceder a la versión original aquí

¡Buenas! A raíz de una situación en la que me he encontrado en un proyecto real (de la que luego hablaré) me he decidido a escribir este post para comentar algunas cosillas sobre varianzas en los delegados mismos.

Cuando hablamos de varianzas en delegados hay que contemplar dos aspectos:

• Varianzas entre los tipos definidos por el delegado y los tipos de la función asignada al delegado
• Varianzas entre _el tipo del delegado _y otros tipos (en este caso object).
• Las combinaciones entre esos dos puntos.

Los delegados son tipos por referencia, como si fuesen una clase. Eso significa que null es un valor aceptado y que no hay boxing/unboxing al convertir a/desde object. Como todos los tipos un delegado hereda de object:

public delegate void MyDelegate(int i, object o);
// Luego en cualquier función
object o = new MyDelegate((i, o) => { });

Eso compila sin problemas: creamos un MyDelegate vinculado a una función anónima (expresada con una expresión lambda) y asignamos el valor a una variable de tipo object.

Observa ahora el siguiente código:

MyDelegate d = new MyDelegate((i, o) => { });

Es obvio que funciona, pero podríamos intentar simplificarlo, eliminando la creación explícita del objeto MyDelegate puesto que la expresión lambda ya define una función válida:

MyDelegate d = (i, o) => { };

Eso es también correcto. En resúmen, ya sea creando explícitamente el objeto delegado (primer caso) o no (segundo caso) podemos asignar una lambda a un delegado, siempre y cuando los parámetros de la lambda sean “compatibles” con la firma del delegado. Para eso, claro está, el compilador debe “inferir” los tipos de los parámetros de la lambda. En este caso asume que el parámetro i es de tipo int y el parámetro _o _es de tipo object, ya que esa es la manera de cumplir con la firma del delegado.

Vale, entonces podemos asignar delegados a objetos y podemos crear delegados a partir de lambdas y el compilador infiere los tipos de los parámetros. Pero, ¿qué ocurre si intentamos asignar un delegado a una función que no se corresponde con la firma del delegado, pero donde hay varianza entre sus parámetros?

Es decir, imagina eso:

MyDelegate d = (int i, string s) => { };

Aquí estamos forzando que el parámetro s de la expresión lambda sea una string. ¿Eso es correcto? Veamos:

• string hereda de object
• Por lo tanto cualquier función que tenga como parámetros (int, object) le podemos pasar (int, string) sin ningún problema.
• Por lo tanto en un delegado (int, object) podemos guardar una función (int, string). (¡Ojo! Que este punto es el que contiene el razonamiento incorrecto. Ahora mismo lo vemos).

A priori parece que eso debería compilar. Pero la realidad es que no. Este código no compila. Vas a recibir un error CS1661:_ Cannot convert lambda expression to delegate type ‘MyDelegate’ because the parameter types do not match the delegate parameter types._

El problema es que hemos asumido, que dado que a cualquier función (int, object) le podemos pasar (int, string), las funciones (int, string) son “como un subtipo” de las funciones (int, object). O dicho de otro modo más técnico: hemos asumido que, como hay covarianza entre los tipos string y object (podemos usar strings donde se esperan objects) habrá covarianza entre los tipos “función (int, object) y “función (int, string)”. Y no es ese el caso.

No hay manera de asignar una función (int, string) a un delegado cuya firma es (int, object). ¡Y con razón! Vamos a verlo con un ejemplo:

Eso no funciona:

public delegate void MyStringDelegate(int i, string s);
public delegate void MyObjectDelegate(int i, object o);
// Luego en cualquier sitio...
MyStringDelegate d = (int i, string s) => { };
MyObjectDelegate t = d;

La última línea da error, diciendo que no puede convertir un delegado (int, string) a un delegado (int, object). Da igual que la covarianza entre string y object. Aquí no aplica.

Podrías tener la tentación de usar in para forzar la covarianza:

public delegate void MyDelegate<in  T>(int i, T o);
MyDelegate<string> d = (int i, string s) => { };
MyDelegate<object> t = d;        // Error CS0266

Eso tampoco te va a compilar.

¿Y por qué no se puede? Pues muy sencillo. Imagina que cualquiera de esos dos códigos fuese posible. Entonces yo podría hacer:

MyDelegate<string> d = (int i, string s) => { };
MyDelegate<object> t = d;
t(1, DateTime.Now);

¡He llamado a una función que aceptaba (int, string) y le he pasado (int, DateTime)! (De hecho le he pasado (int, object), por lo que a la práctica le puedo pasar (int, cualquier cosa)). ¡Es obvio que esto no debe compilar!

Claro, el problema radica en que un delegado me permite invocar a la función que contiene. Así, realmente lo que parece un tema de covarianza (usar strings en lugar de objects) es realmente un problema de contravarianza (usar objects en lugar de strings). Por lo tanto, a pesar de que una variable de tipo object puede contener una string, un delegado cuya firma sea (object) no puede contener una función con firma(string).

Es decir, sí, a cualquier función que acepte (int, object) le podemos pasar (int, string) pero eso ¡¡¡NO es asignar una función (int, string) a un delegado (int, object)!!!

De hecho el uso que hemos intentado con la palabra clave in nos habilita precisamente la conversión contraria:

MyDelegate<object> d = (int i, object s) => { };
MyDelegate<string> t = d;
t(1, "");

Observa como podemos asignar un MyDelegate