Por que covariância e contravariância não suportam tipo de valor

IEnumerable<T>é co-variante, mas não suporta o tipo de valor, apenas o tipo de referência. O código simples abaixo é compilado com sucesso:

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

Mas mudar de stringpara intreceberá um erro compilado:

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

O motivo é explicado no MSDN :

A variação se aplica apenas a tipos de referência; se você especificar um tipo de valor para um parâmetro de tipo variante, esse parâmetro de tipo será invariável para o tipo construído resultante.

Pesquisei e descobri que algumas perguntas mencionavam o motivo do boxe entre o tipo de valor e o tipo de referência . Mas ainda não me lembro muito bem por que o boxe é a razão?

Alguém poderia dar uma explicação simples e detalhada por que covariância e contravariância não suportam o tipo de valor e como o boxe afeta isso?

Basicamente, a variação se aplica quando o CLR pode garantir que não precisa fazer nenhuma alteração representacional nos valores. Todas as referências têm a mesma aparência - para que você possa usar um IEnumerable<string>como um IEnumerable<object>sem nenhuma alteração na representação; o próprio código nativo não precisa saber o que você está fazendo com os valores, desde que a infraestrutura tenha garantido que será definitivamente válido.

Para tipos de valor, isso não funciona - para tratar um IEnumerable<int>como IEnumerable<object>, o código que usa a sequência precisaria saber se deveria ser realizada uma conversão de boxe ou não.

Você pode ler a publicação no blog de Eric Lippert sobre representação e identidade para obter mais informações sobre esse tópico em geral.

EDIT: Depois de reler a postagem do blog de Eric, é pelo menos tanto identidade quanto representação, embora os dois estejam vinculados. Em particular:

É por isso que as conversões covariantes e contravariantes dos tipos de interface e delegado exigem que todos os argumentos de tipo variados sejam de tipos de referência. Para garantir que uma conversão de referência de variante sempre preserve a identidade, todas as conversões que envolvem argumentos de tipo também devem preservar a identidade. A maneira mais fácil de garantir que todas as conversões não triviais nos argumentos de tipo preservem a identidade é restringi-las a serem conversões de referência.

Talvez seja mais fácil entender se você pensar na representação subjacente (mesmo que esse seja realmente um detalhe de implementação). Aqui está uma coleção de strings:

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

Você pode pensar stringsem ter a seguinte representação:

[0]: referência de string -> "A"
[1]: referência de string -> "B"
[2]: referência de string -> "C"

É uma coleção de três elementos, cada um sendo uma referência a uma string. Você pode converter isso em uma coleção de objetos:

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

Basicamente, é a mesma representação, exceto que agora as referências são referências a objetos:

[0]: referência a objeto -> "A"
[1]: referência a objeto -> "B"
[2]: referência a objeto -> "C"

A representação é a mesma. As referências são tratadas apenas de maneira diferente; você não pode mais acessar a string.Lengthpropriedade, mas ainda pode ligar object.GetHashCode(). Compare isso com uma coleção de ints:

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

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

Para converter isso em um, IEnumerable<object>os dados devem ser convertidos com o encaixe das entradas:

[0]: referência a objeto -> 1
[1]: referência a objeto -> 2
[2]: referência a objeto -> 3

Essa conversão requer mais do que um elenco.

Penso que tudo começa com a definição de LSP(Princípio da Substituição de Liskov), que clime:

se q (x) for uma propriedade comprovável sobre objetos x do tipo T, então q (y) deve ser verdadeiro para objetos y do tipo S, em que S é um subtipo de T.

Mas tipos de valor, por exemplo, intnão podem ser substituídos por objectin C#. Prove é muito simples:

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

Isso retorna falsemesmo se atribuirmos a mesma "referência" ao objeto.

Ele se resume a um detalhe de implementação: Tipos de valor são implementados de maneira diferente para tipos de referência.

Se você forçar os tipos de valor a serem tratados como tipos de referência (por exemplo, encaixotá-los, por exemplo, referindo-se a eles por meio de uma interface), poderá obter variação.

A maneira mais fácil de ver a diferença é simplesmente considerar uma Array: uma matriz de tipos de Valor é reunida na memória de forma contígua (diretamente), onde, como uma matriz de tipos de Referência, apenas a referência (um ponteiro) possui contígua na memória; os objetos que estão sendo apontados são alocados separadamente.

A outra questão (relacionada) (*) é que (quase) todos os tipos de referência têm a mesma representação para fins de variação e muito código não precisa saber da diferença entre os tipos, portanto, a covariância e a contravariância são possíveis (e facilmente implementado - geralmente apenas por omissão de verificação de tipo extra).

(*) Pode ser o mesmo problema ...