Contravariance vs Covariance in Scala

Question

I just learned Scala. Now I am confused about Contravariance and Covariance.

From this page, I learned something below:

Covariance

Perhaps the most o

Answer 1

That you can pass a List[Beagle] to a function expecting a List[Dog] is nothing to do with contravariance of functions, it is still because List is covariant and that List[Beagle] is a List[Dog].

Instead lets say you had a function:

def countDogsLegs(dogs: List[Dog], legCountFunction: Dog => Int): Int

This function counts all the legs in a list of dogs. It takes a function that accepts a dog and returns an int representing how many legs this dog has.

Furthermore lets say we have a function:

def countLegsOfAnyAnimal(a: Animal): Int

that can count the legs of any animal. We can pass our countLegsOfAnyAnimal function to our countDogsLegs function as the function argument, this is because if this thing can count the legs of any animal, it can count legs of dogs, because dogs are animals, this is because functions are contravariant.

If you look at the definition of Function1 (functions of one parameter), it is

trait Function1[-A, +B]

That is that they are contravariant on their input and covariant on their output. So Function1[Animal,Int] <: Function1[Dog,Int] since Dog <: Animal

Answer 2

A Good recent article (August 2016) on that topic is "Cheat Codes for Contravariance and Covariance" by Matt Handler.

It starts from the general concept as presented in "Covariance and Contravariance of Hosts and Visitors" and diagram from Andre Tyukin and anoopelias's answer.

And its concludes with:

Here is how to determine if your type ParametricType[T] can/cannot be covariant/contravariant:

• A type can be covariant when it does not call methods on the type that it is generic over.
  If the type needs to call methods on generic objects that are passed into it, it cannot be covariant.

Archetypal examples:

Seq[+A], Option[+A], Future[+T]

• A type can be contravariant when it does call methods on the type that it is generic over.
  If the type needs to return values of the type it is generic over, it cannot be contravariant.

Archetypal examples:

`Function1[-T1, +R]`, `CanBuildFrom[-From, -Elem, +To]`, `OutputChannel[-Msg]`

Regarding contravariance,

Functions are the best example of contravariance
(note that they’re only contravariant on their arguments, and they’re actually covariant on their result).
For example:

class Dachshund(
  name: String,
  likesFrisbees: Boolean,
  val weinerness: Double
) extends Dog(name, likesFrisbees)

def soundCuteness(animal: Animal): Double =
  -4.0/animal.sound.length

def weinerosity(dachshund: Dachshund): Double =
  dachshund.weinerness * 100.0

def isDogCuteEnough(dog: Dog, f: Dog => Double): Boolean =
  f(dog) >= 0.5

Should we be able to pass weinerosity as an argument to isDogCuteEnough? The answer is no, because the function isDogCuteEnough only guarantees that it can pass, at most specific, a Dog to the function f.
When the function f expects something more specific than what isDogCuteEnough can provide, it could attempt to call a method that some Dogs don’t have (like .weinerness on a Greyhound, which is insane).

Answer 3

Variance is used to indicate subtyping in terms of Containers(eg: List). In most of the languages, if a function requests object of Class Animal, passing any class that inherits Animal(eg: Dog) would be valid. However, in terms of Containers, these need not be valid. If your function wants Container[A], what are the possible values that can be passed to it? If B extends A and passing Container[B] is valid, then it is Covariant(eg: List[+T]). If, A extends B(the inverse case) and passing Container[B] for Container[A] is valid, then it is Contravariant. Else, it is invariant(which is the default). You could refer to an article where I have tried explaining variances in Scala https://lakshmirajagopalan.github.io/variance-in-scala/.