La Variance ne seront pris en charge dans un sûr moyen - en fait, en utilisant les capacités que le CLR a déjà. Donc les exemples que je donne dans le livre d'essayer d'utiliser un List<Banana> comme List<Fruit> (ou de ce qu'il était) ne fonctionne toujours pas - mais quelques autres scénarios.
Tout d'abord, il sera uniquement pris en charge pour les délégués et les interfaces.
Deuxièmement, il demande à l'auteur de l'interface/délégué pour décorer le type de paramètres que l' in (pour la contravariance) ou out (pour la covariance). L'exemple le plus évident est - IEnumerable<T> qui n'a jamais permet de prendre des valeurs "en dehors" d'il - il ne vous laisse pas en ajouter de nouvelles. Que deviendra IEnumerable<out T>. Qui ne fait pas de mal de type de sécurité, mais vous permet de retourner un IEnumerable<string> à partir d'une méthode déclarée pour retourner IEnumerable<object> par exemple.
La Contravariance est plus difficile de donner des exemples concrets de l'utilisation des interfaces, mais il est facile avec un délégué. Envisager Action<T> - qui représente une méthode qui prend un T paramètre. Il serait agréable d'être en mesure de convertir les utiliser de manière transparente un Action<object> comme Action<string> - toute méthode qui prend un object paramètre va être bien quand il est présenté avec un string à la place. Bien sûr, C# 2 a déjà la covariance et la contravariance des délégués, dans une certaine mesure, mais par le biais d'une conversion d'un type délégué à l'autre (la création d'une nouvelle instance) - voir P141-144 pour des exemples. C# 4 va le rendre plus générique, et (je crois) permettra d'éviter la création d'une nouvelle instance pour la conversion. (Ça va être un conversion de référence à la place.)
Espérons que cela efface un peu - s'il vous plaît laissez-moi savoir si ça n'a pas de sens!
