¿Por qué C# (4.0) no permite co y contravariancia en tipos de clases genéricas?

Question

¿Cuál es la razón real por esa limitación? ¿Es solo trabajo lo que debe hacerse? ¿Es conceptualmente difícil? ¿Es imposible?

Seguro, no se podían usar los parámetros de tipo en los campos, porque son siempre de lectura-escritura. Pero esa no puede ser la respuesta, ¿verdad?

El motivo de esta pregunta es que estoy escribiendo un artículo sobre soporte de varianza en C# 4, y creo que debería explicar por qué está restringido a delegados e interfaces. Solo para invertir la carga de la prueba.

Actualización: Eric preguntó sobre un ejemplo.

¿Qué hay de esto (no sé si eso tiene sentido, sin embargo :-))

public class Lookup<out T> where T : Animal { 
    public T Find(string name) { 
    Animal a = _cache.FindAnimalByName(name); 
    return a as T; 
    } 
} 

var findReptiles = new Lookup<Reptile>(); 
Lookup<Animal> findAnimals = findReptiles; 

La razón de tener que en una clase podría ser el caché que se llevó a cabo en la propia clase. ¡Y por favor no nombre a sus diferentes mascotas de la misma forma!

Por cierto, esto me lleva a optional type parameters in C# 5.0 :-)

Actualización 2: No estoy afirmando que el CLR y C# debería permitir esto. Solo estoy tratando de entender lo que me llevó a eso.

Answer 1

En primer lugar, como dice Tomás, que no se admite en el CLR.

En segundo lugar, ¿cómo funcionaría? Supongamos que tiene

class C<out T> 
{ ... how are you planning on using T in here? ... } 

T solo se puede utilizar en las posiciones de salida. Como nota, la clase no puede tener ningún campo de tipo T porque el campo podría escribirse. La clase no puede tener ningún método que tome una T, porque lógicamente se escribe. Supongamos que tiene esta característica: ¿cómo podría aprovecharla?

Esto sería útil para clases inmutables si pudiéramos, por ejemplo, hacer legal tener un campo de solo lectura de tipo T; De esa forma, redujimos masivamente la probabilidad de que se escribiera incorrectamente. Pero es bastante difícil encontrar otros escenarios que permitan la variación de una manera segura.

Si tiene este tipo de escenario, me encantaría verlo. Eso sería puntos para algún día implementar esto en el CLR.

ACTUALIZACIÓN: Ver

Why isn't there generic variance for classes in C# 4.0?

para más información sobre esta cuestión.

Answer 2

Hasta donde yo sé, esta función no es compatible con CLR, por lo que agregar esto también requeriría un trabajo importante en el lado de CLR. Creo que la contra varianza para las interfaces y los delegados en realidad era compatible con CLR antes de la versión 4.0, por lo que esta fue una extensión relativamente sencilla de implementar.

(Apoyando esta característica para las clases serían sin duda útil, sin embargo!)

Answer 3

Si se permitieran, se podrían definir clases o estructuras útiles 100% tipo seguro (sin tipografías internas) que fueran covariantes con respecto a su tipo T, si su constructor aceptara una o más empresas T o T. Se podrían definir clases o estructuras útiles, 100% de tipo seguro, que fueran contravariantes con respecto a T si sus constructores aceptaran uno o más consumidores de T. No estoy seguro de que haya mucha ventaja de una clase sobre una interfaz, más allá de la capacidad de usar "nuevo" en lugar de utilizar un método de fábrica estático (muy probablemente de una clase cuyo nombre es similar al de la interfaz), pero puedo sin duda, los casos de uso para tener estructuras inmutables apoyan la covarianza.