Covariance is pretty simple and best thought of from the perspective of some collection class List. We can parameterize the List class with some type parameter T. That is, our list contains elements of type T for some T. List would be covariant if S is a subtype of T iff List[S] is a subtype … Read more
The canonical example is a .clone()/.copy() method. So you can always do obj = obj->copy(); regardless what obj’s type is. Edit: This clone method would be defined in the Object base class (as it actually is in Java). So if clone wasn’t covariant, you would either have to cast, or would be restricted to methods … Read more
Covariance and contravariance are qualities of the class not qualities of the parameters. (They are qualities that depend on the parameters, but they make statements about the class.) So, Function1[-A,+B] means that a function that takes superclasses of A can be viewed as a subclass of the original function. Let’s see this in practice: class … Read more
This answer is not talking about C#, but it helped me understand the issues better and maybe it will help others: Why is there no parameter contra-variance for overriding?
You can re-declare (new), but you can’t re-declare and override at the same time (with the same name). One option is to use a protected method to hide the detail – this allows both polymorphism and hiding at the same time: public class Father { public Father SomePropertyName { get { return SomePropertyImpl(); } } … Read more
vector<Base*> and vector<Derived*> are unrelated types, so you can’t do this. This is explained in the C++ FAQ here. You need to change your variable from a vector<Derived*> to a vector<Base*> and insert Derived objects into it. Also, to avoid copying the vector unnecessarily, you should pass it by const-reference, not by value: void BaseFoo( … Read more
Because it would break type-safety otherwise. If not, you would be able to do something like this: val arr:Array[Int] = Array[Int](1,2,3) val arr2:Array[Any] = arr arr2(0) = 2.54 and the compiler can’t catch it. On the other hand, lists are immutable, so you can’t add something that is not Int
You could write your own read-only wrapper for the dictionary, e.g.: public class ReadOnlyDictionaryWrapper<TKey, TValue, TReadOnlyValue> : IReadOnlyDictionary<TKey, TReadOnlyValue> where TValue : TReadOnlyValue { private IDictionary<TKey, TValue> _dictionary; public ReadOnlyDictionaryWrapper(IDictionary<TKey, TValue> dictionary) { if (dictionary == null) throw new ArgumentNullException(“dictionary”); _dictionary = dictionary; } public bool ContainsKey(TKey key) { return _dictionary.ContainsKey(key); } public IEnumerable<TKey> Keys … Read more
Firstly, this is indeed how it works in C++: the return type of a virtual function in a derived class must be the same as in the base class. There is the special exception that a function that returns a reference/pointer to some class X can be overridden by a function that returns a reference/pointer … Read more
Simply put, IList<T> is not covariant, whereas IEnumerable<T> is. Here’s why… Suppose IList<T> was covariant. The code below is clearly not type-safe… but where would you want the error to be? IList<Apple> apples = new List<Apple>(); IList<Fruit> fruitBasket = apples; fruitBasket.Add(new Banana()); // Aargh! Added a Banana to a bunch of Apples! Apple apple = … Read more