Why do covariance/contravariance imply read-only/write-only?

Question

If you take a look at the flow docs on covariant/contravariant fields in interfaces, covariant implies read-only and contravariance implies write-only. However, I don't really understand why. In their docs on variance, they're defined as

Covariance

• Covariance does not accept supertypes.
• Covariance does accept subtypes.

Contravariance

• Contravariance does accept supertypes.
• Contravariance does not accept subtypes.

But that doesn't really map to read-only/write-only in my mind. Could anyone explain more in depth why it's the case?

Answer 1

I'm not familiar with the syntax of the language, so this answer is in pseudo-code.

Imagine we have three types, Siamese < Cat < Animal, and define an interface

interface CatCage {
    cat: Cat
}

and write some methods

get_cat_in_cage (CatCage c) -> Cat {
    c.cat
}

put_cat_in_cage (Cat c, CatCage cage) {
    cage.cat = c
}

Covariance

If we make the field covariant, we can define an instance like

SiameseCage < CatCage {
    cat : Siamese
}

But if we do

put_cat_in_cage (aCat, aSiameseCage)

What is the value of aSiameseCage.cat in this instance? SiameseCage thinks it ought to be a Siamese, but we've just been able to make it a Cat - clearly, the field can't be writeable on the interface and be covariant at the same time.

Contravariance

If we make the field contravariant, we can define an instance like

AnimalCage < CatCage {
    cat : Animal
}

But now we can't do

get_cat_in_cage (anAnimalCage)

As the value of anAnimalCage.cat isn't guaranteed to be a Cat. So the field can't be readable on the interface if it's contravariant.

You could potentially make it readable on the interface by returning an Object, or whatever the base type is, but that probably wouldn't have any real use case, so the language is sensible in deciding against it.