Perché la covarianza e la contraddizione non supportano il tipo di valore

IEnumerable<T>è una variante, ma non supporta il tipo di valore, ma solo il tipo di riferimento. Il codice semplice di seguito è stato compilato correttamente:

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

Ma cambiando da stringa intsi otterrà un errore compilato:

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

Il motivo è spiegato in MSDN :

La varianza si applica solo ai tipi di riferimento; se si specifica un tipo di valore per un parametro di tipo variante, quel parametro di tipo è invariante per il tipo costruito risultante.

Ho cercato e trovato che alcune domande menzionavano il motivo è la boxe tra il tipo di valore e il tipo di riferimento . Ma non mi chiarisce ancora molto perché la boxe è la ragione?

Qualcuno potrebbe fornire una spiegazione semplice e dettagliata perché la covarianza e la contraddizione non supportano il tipo di valore e in che modo la boxe influisce su questo?

Fondamentalmente, la varianza si applica quando il CLR può garantire che non è necessario apportare alcuna modifica rappresentativa ai valori. I riferimenti sembrano tutti uguali - quindi puoi usare un IEnumerable<string>as come IEnumerable<object>senza alcun cambiamento nella rappresentazione; il codice nativo stesso non ha bisogno di sapere cosa stai facendo con i valori, purché l'infrastruttura abbia garantito che sarà sicuramente valida.

Per i tipi di valore, che non funziona: per trattare un IEnumerable<int>come IEnumerable<object>, il codice che utilizza la sequenza dovrebbe sapere se eseguire o meno una conversione di boxe.

Potresti leggere il post sul blog di Eric Lippert su rappresentazione e identità per ulteriori informazioni su questo argomento in generale.

EDIT: Dopo aver riletto il post sul blog di Eric, si tratta almeno dell'identità quanto della rappresentazione, sebbene i due siano collegati. In particolare:

Questo è il motivo per cui le conversioni covarianti e controverse di tipi di interfaccia e delegati richiedono che tutti gli argomenti di tipo variabile siano di tipo di riferimento. Per garantire che una conversione di riferimento di variante mantenga sempre l'identità, tutte le conversioni che coinvolgono argomenti di tipo devono anche preservare l'identità. Il modo più semplice per garantire che tutte le conversioni non banali su argomenti di tipo preservino l'identità è di limitarle a conversioni di riferimento.

È forse più facile da capire se si pensa alla rappresentazione sottostante (anche se questo è davvero un dettaglio di implementazione). Ecco una raccolta di stringhe:

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

Puoi pensare stringsche abbia la seguente rappresentazione:

[0]: riferimento stringa -> "A"
[1]: riferimento stringa -> "B"
[2]: riferimento stringa -> "C"

È una raccolta di tre elementi, ognuno dei quali è un riferimento a una stringa. Puoi lanciarlo in una raccolta di oggetti:

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

Fondamentalmente è la stessa rappresentazione, tranne ora che i riferimenti sono riferimenti a oggetti:

[0]: riferimento oggetto -> "A"
[1]: riferimento oggetto -> "B"
[2]: riferimento oggetto -> "C"

La rappresentazione è la stessa. I riferimenti sono semplicemente trattati in modo diverso; non puoi più accedere alla string.Lengthproprietà ma puoi comunque chiamare object.GetHashCode(). Confronta questo con una raccolta di ints:

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

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

Per convertire questo in un IEnumerable<object>i dati devono essere convertiti inscatolando gli ints:

[0]: riferimento oggetto -> 1
[1]: riferimento oggetto -> 2
[2]: riferimento oggetto -> 3

Questa conversione richiede più di un cast.

Penso che tutto inizi da definiton di LSP(principio di sostituzione di Liskov), che sale:

se q (x) è una proprietà dimostrabile sugli oggetti x di tipo T, allora q (y) dovrebbe essere vero per gli oggetti y di tipo S dove S è un sottotipo di T.

Ma i tipi di valore, ad esempio, intnon possono essere sostituiti da objectin C#. Dimostrare è molto semplice:

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

Ciò ritorna falseanche se assegniamo lo stesso "riferimento" all'oggetto.

Dipende da un dettaglio di implementazione: i tipi di valore sono implementati in modo diverso dai tipi di riferimento.

Se si forzano i tipi di valore a essere trattati come tipi di riferimento (ad esempio, riordinarli, ad es. Facendo riferimento a essi tramite un'interfaccia) è possibile ottenere una varianza.

Il modo più semplice per vedere la differenza è semplicemente considerare un Array: una matrice di tipi di valore è messa insieme in memoria contigua (direttamente), dove come una matrice di tipi di riferimento ha solo il riferimento (un puntatore) contiguo nella memoria; gli oggetti puntati sono assegnati separatamente.

L'altro problema (correlato) (*) è che (quasi) tutti i tipi di riferimento hanno la stessa rappresentazione ai fini della varianza e molto codice non ha bisogno di conoscere la differenza tra i tipi, quindi è possibile (e facilmente) implementato - spesso solo per omissione del controllo extra del tipo).

(*) Potrebbe essere considerato lo stesso problema ...