Dlaczego kowariancja i kontrawariancja nie obsługują typu wartości

IEnumerable<T>jest kowariancją, ale nie obsługuje typu wartości, tylko typ referencyjny. Poniższy prosty kod został pomyślnie skompilowany:

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

Ale zmiana z stringna intspowoduje błąd kompilacji:

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

Powód jest wyjaśniony w MSDN :

Wariancja dotyczy tylko typów referencyjnych; jeśli określisz typ wartości dla parametru typu wariantu, ten parametr typu jest niezmienny dla wynikowego typu skonstruowanego.

Przeszukałem i stwierdziłem, że w niektórych pytaniach wspomniano, że powodem jest boksowanie między typem wartości a typem odniesienia . Ale to wciąż nie wyjaśnia mi zbytnio, dlaczego powodem jest boks?

Czy ktoś mógłby podać proste i szczegółowe wyjaśnienie, dlaczego kowariancja i kontrawariancja nie obsługują typu wartości i jak wpływa na to boks ?

Zasadniczo wariancja ma zastosowanie, gdy środowisko CLR może zapewnić, że nie musi dokonywać żadnych reprezentacyjnych zmian wartości. Wszystkie odwołania wyglądają tak samo - możesz więc użyć IEnumerable<string>jakoIEnumerable<object> bez żadnych zmian w reprezentacji; sam kod natywny nie musi w ogóle wiedzieć, co robisz z wartościami, o ile infrastruktura gwarantuje, że na pewno będzie poprawna.

W przypadku typów wartości to nie działa - aby traktować IEnumerable<int>jako plikIEnumerable<object> , kod używający sekwencji musiałby wiedzieć, czy wykonać konwersję pudełkową, czy nie.

Możesz przeczytać wpis na blogu Erica Lipperta na temat reprezentacji i tożsamości aby uzyskać więcej ogólnych informacji na ten temat.

EDYCJA: Po ponownym przeczytaniu posta na blogu Erica, chodzi przynajmniej w takim samym stopniu o tożsamość, jak o reprezentację, chociaż te dwa elementy są połączone. W szczególności:

Dlatego konwersje kowariantne i kontrawariantne typów interfejsu i delegatów wymagają, aby wszystkie argumenty różnych typów były typami odwołań. Aby upewnić się, że konwersja odwołania do wariantu zawsze zachowuje tożsamość, wszystkie konwersje obejmujące argumenty typu muszą również zachowywać tożsamość. Najłatwiejszym sposobem na zapewnienie, że wszystkie nietrywialne konwersje argumentów typu zachowują tożsamość, jest ograniczenie ich do konwersji odwołań.

Być może łatwiej będzie to zrozumieć, jeśli pomyślisz o podstawowej reprezentacji (nawet jeśli tak naprawdę jest to szczegół implementacji). Oto zbiór ciągów:

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

Możesz myśleć o tym, stringsże ma następującą reprezentację:

[0]: odwołanie do ciągu -> „A”
[1]: odwołanie do ciągu -> "B"
[2]: odwołanie do ciągu -> "C"

Jest to zbiór trzech elementów, z których każdy jest odniesieniem do łańcucha. Możesz przesłać to do kolekcji obiektów:

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

Zasadniczo jest to ta sama reprezentacja, z wyjątkiem tego, że teraz odniesienia są odniesieniami do obiektów:

[0]: odwołanie do obiektu -> „A”
[1]: odniesienie do obiektu -> „B”
[2]: odniesienie do obiektu -> "C"

Reprezentacja jest taka sama. Odniesienia są po prostu traktowane inaczej; nie masz już dostępu do string.Lengthnieruchomości, ale nadal możesz zadzwonić object.GetHashCode(). Porównaj to ze zbiorem liczb int:

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

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

Aby przekonwertować to IEnumerable<object>na dane, należy przekonwertować je, umieszczając w ramkach int:

[0]: odniesienie do obiektu -> 1
[1]: odniesienie do obiektu -> 2
[2]: odniesienie do obiektu -> 3

Ta konwersja wymaga czegoś więcej niż obsady.

Myślę, że wszystko zaczyna się od określenia LSP(Zasada Zastępstwa Liskova), które klimaty:

jeśli q (x) jest właściwością możliwą do udowodnienia w odniesieniu do obiektów x typu T, to q (y) powinno być prawdziwe dla obiektów y typu S, gdzie S jest podtypem T.

Ale typów wartości, na przykład, intnie można zastąpić objectin C#. Udowodnienie jest bardzo proste:

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

Zwraca to falsenawet, jeśli przypiszemy to samo „odniesienie” do obiektu.

Sprowadza się to do szczegółu implementacji: typy wartości są implementowane inaczej niż typy referencyjne.

Jeśli wymuszasz, aby typy wartości były traktowane jako typy referencyjne (tj. Umieszczaj je w pudełku, np. Odwołując się do nich przez interfejs), możesz uzyskać wariancję.

Najłatwiejszym sposobem dostrzeżenia różnicy jest po prostu rozważenie Array: tablica typów wartości jest umieszczana w pamięci w sposób ciągły (bezpośrednio), podczas gdy jako tablica typów referencyjnych tylko odwołanie (wskaźnik) jest ciągłe w pamięci; wskazywane obiekty są przydzielane oddzielnie.

Inną (pokrewną) kwestią (*) jest to, że (prawie) wszystkie typy referencyjne mają tę samą reprezentację dla celów wariancji, a znaczna część kodu nie musi znać różnicy między typami, więc współ- i przeciwwariancja jest możliwa (i łatwo zaimplementowane - często po prostu przez pominięcie dodatkowego sprawdzania typu).

(*) Może to być ten sam problem ...