Почему ковариация и контравариантность не поддерживают тип значения

IEnumerable<T>является ко-вариантом, но не поддерживает тип значения, только ссылочный тип. Приведенный ниже простой код успешно скомпилирован:

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

Но переход от stringк intполучит скомпилированную ошибку:

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

Причина объясняется в MSDN :

Дисперсия применяется только к ссылочным типам; если вы указываете тип значения для параметра типа варианта, этот параметр типа является инвариантным для результирующего составного типа.

Я искал и обнаружил, что в некоторых вопросах упоминается причина - бокс между типом значения и ссылочным типом . Но это все еще не проясняет мой разум, почему бокс является причиной?

Может ли кто-нибудь дать простое и подробное объяснение, почему ковариация и контравариантность не поддерживают тип значения и как бокс влияет на это?

В основном, дисперсия применяется, когда CLR может гарантировать, что ему не нужно вносить какие-либо репрезентативные изменения в значения. Ссылки выглядят одинаково - так что вы можете использовать IEnumerable<string>как IEnumerable<object>без каких-либо изменений в представлении; самому нативному коду вообще не нужно знать, что вы делаете со значениями, если инфраструктура гарантирует, что он определенно будет действительным.

Для типов значений, которые не работают - лечить IEnumerable<int>как IEnumerable<object>код с использованием последовательности должен знать , следует ли выполнять преобразование бокса или нет.

Возможно, вы захотите прочитать сообщение Эрика Липперта в блоге о представительстве и идентичности, чтобы узнать больше об этой теме в целом.

РЕДАКТИРОВАТЬ: Перечитав сообщение в блоге Эрика самостоятельно, это по крайней мере так же, как личность, как представление, хотя оба связаны. В частности:

Вот почему ковариантные и контравариантные преобразования типов интерфейса и делегата требуют, чтобы все переменные аргументы типа имели ссылочные типы. Чтобы преобразование ссылки на вариант всегда сохраняло идентичность, все преобразования, включающие аргументы типа, также должны сохранять идентичность. Самый простой способ убедиться, что все нетривиальные преобразования в аргументах типа сохраняют идентичность, - это ограничить их ссылочными преобразованиями.

Возможно, это будет легче понять, если вы подумаете о базовом представлении (даже если это действительно детали реализации). Вот коллекция строк:

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

Вы можете думать о том, чтобы stringsиметь следующее представление:

[0]: ссылка на строку -> "A"
[1]: ссылка на строку -> "B"
[2]: ссылка на строку -> "C"

Это коллекция из трех элементов, каждый из которых является ссылкой на строку. Вы можете привести это к коллекции объектов:

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

По сути, это то же представление, за исключением того, что теперь ссылки являются ссылками на объекты:

[0]: ссылка на объект -> "A"
[1]: ссылка на объект -> "B"
[2]: ссылка на объект -> "C"

Представление то же самое. Ссылки просто по-разному трактуются; Вы больше не можете получить доступ к string.Lengthсобственности, но вы все равно можете позвонить object.GetHashCode(). Сравните это с коллекцией целых:

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

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

Чтобы преобразовать это IEnumerable<object>в данные, необходимо преобразовать их в боксы:

[0]: ссылка на объект -> 1
[1]: ссылка на объект -> 2
[2]: ссылка на объект -> 3

Это преобразование требует больше, чем приведение.

Я думаю, что все начинается с определения LSP(принцип подстановки Лискова), который гласит:

если q (x) является свойством, доказуемым для объектов x типа T, тогда q (y) должно быть истинным для объектов y типа S, где S является подтипом T.

Но типы значений, например, intне могут быть заменены objectв C#. Доказать это очень просто:

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

Это возвращает, falseдаже если мы назначаем ту же «ссылку» на объект.

Это сводится к деталям реализации: типы значений реализуются иначе, чем ссылочные типы.

Если вы заставите типы значений обрабатываться как ссылочные типы (т. Е. Пометить их, например, путем обращения к ним через интерфейс), вы можете получить дисперсию.

Самый простой способ увидеть разницу - это просто рассмотреть Array: массив типов значений объединяется в памяти непрерывно (напрямую), где в качестве массива ссылочных типов имеется только ссылка (указатель) непрерывно в памяти; объекты, на которые указывают, выделяются отдельно.

Другая (связанная) проблема (*) заключается в том, что (почти) все ссылочные типы имеют одно и то же представление для целей дисперсии, и большой части кода не нужно знать о разнице между типами, поэтому возможна совместная и противоположная дисперсия (и легко реализовано - часто просто из-за отсутствия дополнительной проверки типов).

(*) Может быть, это та же проблема ...