Covariance, Contravariance, and Super Type Constraints

Covariance and contravariance are intimately related to "mapping" and only incidentally related to subtype polymorphism. In particular, if we assume we have a function

    coerce : a -> b

which can only be applied when a is a subtype of b then we can dispense with subtyping entirely through explicit coercion.

Now, covariance occurs when you can "map" over a structure "in the same direction".

    mapCovariant : (a -> b) -> (f a -> f b)

while contravariance occurs when maps "flip"

    mapContravariant : (a -> b) -> (f b -> f a)

and we get the subtyping relationship naturally from applying coerce

    covariantCoerce = mapCovariant coerce
    contravariantCoerce = mapContravariant coerce

Now all of this only applies "mathematically" where things are necessarily constant. This implies that we ought to think of mapCovariant and mapContravariant as working on "transformations of data" instead of operating imperatively.

In the event that we have mutability then we can violate covariance and contravariance as noted. Really, though, this is a consequence of a larger problem.

In any mutable type we can apply a transformation on that type while maintaining all references to it

    a = [1, 2, 3];
    a.mapCovariant(fun (x) -> repeat "a" x);

    // a : [String]
    // a == ["a", "aa", "aaa"]

If we're adamant about treating things as transformations then functions like mapCovariant cannot operate mutably since they allow the changing of a generic type.

This is a fantastic explanation of covariance and contravariance. Much better than most explanations I've seen from the Scala community.

f-bounded types (such as in the article) still leave properties to be desired, however: http://tpolecat.github.io/2015/04/29/f-bounds.html

Ahhhh, *variance.

The definitive explanation of why inheritance should always be avoided in favour of implementation of abstract interfaces.