Czy kowariancja/kontrawariancja ma zastosowanie do niejawnie konwertowalnych typów, które nie implementują wspólnego interfejsu?

Question

Obecnie czytam na temat kowariancji i kontrawariancji w języku C#.

Wszystkie przykłady zawierają szczegóły obiektów podlegających zamianie i różnią się ze względu na dokładność implementacji interfejsu, np.

Gdzie Circle : IShape

kowariancji: SomeType<Circle> as SomeType<IShape>
kontrawariancja: SomeType<IShape> as SomeType<Circle>

---

Jeśli TypeA i TypeB każdy mieć implicit converter napisany do konwersji do innego typu, ale nie realizują żadnej Common Interface , czy nadal słuszne jest mówienie o kowariancji/kontrawariancji w odniesieniu do konwersji generyków e typy? Czy to inna koncepcja?

Answer 1

Różne pojęcia. Kowariancja w sensie out (lub contrawariancji przez in) jest zawsze zachowywana przez odniesienie, bez żadnej transformacji - tylko to samo odniesienie w innych (możliwych do udowodnienia) terminach. Z tego też powodu nie ma zastosowania do struktur implementujących interfejs, ponieważ pudełko nie zachowuje referencji. Ta sama logika zachowywania referencji dotyczy kowariantnego przypisania tablic typów referencyjnych.

Answer 2

Typy nie muszą implementować wspólnego interfejsu, aby być co/contra-wariantem.

Pojęcia odnoszą się po prostu do tego, czy konwersja spowoduje utratę informacji lub potencjalny wzrost informacji. Jest to równie istotne, gdy jest stosowane do dziedziczonych obiektów, tak jak to ma miejsce w przypadku podwójnych i pływających.

A więc tak, wciąż jest właściwe mówić o współbieżności i kontraście, gdy mówimy o obiektach, które nie mają wspólnego interfejsu, o ile istnieje niejawny konwerter.