Pourquoi la covariance et la contravariance ne prennent pas en charge le type valeur

IEnumerable<T>est co-variant mais il ne prend pas en charge le type valeur, seulement le type référence. Le code simple ci-dessous est compilé avec succès:

IEnumerable<string> strList = new List<string>();
IEnumerable<object> objList = strList;

Mais changer de stringà intentraînera une erreur de compilation:

IEnumerable<int> intList = new List<int>();
IEnumerable<object> objList = intList;

La raison est expliquée dans MSDN :

La variance s'applique uniquement aux types de référence; si vous spécifiez un type valeur pour un paramètre de type variant, ce paramètre de type est invariant pour le type construit résultant.

J'ai recherché et trouvé que certaines questions mentionnaient que la raison était la boxe entre le type de valeur et le type de référence . Mais cela ne m'éclaircit pas encore beaucoup pourquoi la boxe est la raison?

Quelqu'un pourrait-il donner une explication simple et détaillée pourquoi la covariance et la contravariance ne prennent pas en charge le type de valeur et comment la boxe affecte cela?

Fondamentalement, la variance s'applique lorsque le CLR peut garantir qu'il n'a pas besoin de modifier la représentation des valeurs. Les références se ressemblent toutes - vous pouvez donc utiliser un IEnumerable<string>comme un IEnumerable<object>sans aucun changement de représentation; le code natif lui-même n'a pas du tout besoin de savoir ce que vous faites avec les valeurs, tant que l'infrastructure a garanti qu'elle sera définitivement valide.

Pour les types valeur, cela ne fonctionne pas - pour traiter un IEnumerable<int>comme un IEnumerable<object>, le code utilisant la séquence devrait savoir s'il faut effectuer une conversion de boxe ou non.

Vous voudrez peut-être lire l' article de blog d' Eric Lippert sur la représentation et l'identité pour en savoir plus sur ce sujet en général.

EDIT: Après avoir relu le blog d'Eric moi-même, c'est au moins autant une question d' identité que de représentation, bien que les deux soient liés. En particulier:

C'est pourquoi les conversions covariantes et contravariantes des types d'interface et de délégué nécessitent que tous les arguments de type variables soient de types référence. Pour garantir qu'une conversion de référence de variante préserve toujours l'identité, toutes les conversions impliquant des arguments de type doivent également préserver l'identité. Le moyen le plus simple de garantir que toutes les conversions non triviales sur les arguments de type préservent l'identité est de les limiter à des conversions de référence.

Il est peut-être plus facile à comprendre si vous pensez à la représentation sous-jacente (même s'il s'agit vraiment d'un détail d'implémentation). Voici une collection de chaînes:

IEnumerable<string> strings = new[] { "A", "B", "C" };

Vous pouvez considérer le stringscomme ayant la représentation suivante:

[0]: référence de chaîne -> "A"
[1]: référence de chaîne -> "B"
[2]: référence de chaîne -> "C"

C'est une collection de trois éléments, chacun étant une référence à une chaîne. Vous pouvez convertir ceci en une collection d'objets:

IEnumerable<object> objects = (IEnumerable<object>) strings;

En gros, c'est la même représentation sauf que maintenant les références sont des références d'objet:

[0]: référence objet -> "A"
[1]: référence objet -> "B"
[2]: référence objet -> "C"

La représentation est la même. Les références sont simplement traitées différemment; vous ne pouvez plus accéder à la string.Lengthpropriété mais vous pouvez toujours appeler object.GetHashCode(). Comparez ceci à une collection d'entiers:

IEnumerable<int> ints = new[] { 1, 2, 3 };

[0]: int = 1
[1]: int = 2
[2]: int = 3

Pour convertir cela en un, IEnumerable<object>les données doivent être converties en encadrant les entiers:

[0]: référence d'objet -> 1
[1]: référence objet -> 2
[2]: référence objet -> 3

Cette conversion nécessite plus qu'un casting.

Je pense que tout commence par la définition du LSP(Principe de substitution de Liskov), qui clime:

si q (x) est une propriété prouvable sur les objets x de type T alors q (y) devrait être vrai pour les objets y de type S où S est un sous-type de T.

Mais les types valeur, par exemple, intne peuvent pas remplacer objectin C#. Prouver est très simple:

int myInt = new int();
object obj1 = myInt ;
object obj2 = myInt ;
return ReferenceEquals(obj1, obj2);

Cela revient falsemême si nous attribuons la même "référence" à l'objet.

Cela se résume à un détail d'implémentation: les types valeur sont implémentés différemment des types référence.

Si vous forcez les types de valeur à être traités comme des types de référence (c.-à-d. Les encadrer, par exemple en y faisant référence via une interface), vous pouvez obtenir la variance.

La façon la plus simple de voir la différence est simplement de considérer un Array: un tableau de types Value est mis ensemble en mémoire de manière contiguë (directement), alors qu'en tant que tableau de types Reference, seuls la référence (un pointeur) est contiguë en mémoire; les objets pointés sont alloués séparément.

L'autre problème (lié) (*) est que (presque) tous les types de référence ont la même représentation à des fins de variance et qu'une grande partie du code n'a pas besoin de connaître la différence entre les types, donc la co- et la contre-variance sont possibles (et facilement mis en œuvre - souvent simplement par omission d'une vérification de type supplémentaire).

(*) On peut considérer que c'est le même problème ...