Questions And Answers

More Tutorials

Scala Type Variance



The + symbol marks a type parameter as covariant - here we say that "Producer is covariant on A":

trait Producer[+A] {
 def produce: A

A covariant type parameter can be thought of as an "output" type. Marking A as covariant asserts that Producer[X] <: Producer[Y] provided that X <: Y. For example, a Producer[Cat] is a valid Producer[Animal], as all produced cats are also valid animals.

A covariant type parameter cannot appear in contravariant (input) position. The following example will not compile as we are asserting that Co[Cat] <: Co[Animal], but Co[Cat] has def handle(a: Cat): Unit which cannot handle any Animal as required by Co[Animal]!

trait Co[+A] {
 def produce: A
 def handle(a: A): Unit

One approach to dealing with this restriction is to use type parameters bounded by the covariant type parameter. In the following example, we know that B is a supertype of A. Therefore given Option[X] <: Option[Y] for X <: Y, we know that Option[X]'s def getOrElse[B >: X](b: => B): B can accept any supertype of X - which includes the supertypes of Y as required by Option[Y]:

trait Option[+A] {
 def getOrElse[B >: A](b: => B): B


By default all type parameters are invariant - given trait A[B], we say that "A is invariant on B". This means that given two parametrizations A[Cat] and A[Animal], we assert no sub/superclas relationship between these two types - it does not hold that A[Cat] <: A[Animal] nor that A[Cat] >: A[Animal] regardless of the relationship between Cat and Animal.

Variance annotations provide us with a means of declaring such a relationship, and imposes rules on the usage of type parameters so that the relationship remains valid.


The - symbol marks a type parameter as contravariant - here we say that "Handler is contravariant on A":
trait Handler[-A] {
 def handle(a: A): Unit

A contravariant type parameter can be thought of as an "input" type. Marking A as contravariant asserts that Handler[X] <: Handler[Y] provided that X >: Y. For example a Handler[Animal] is a valid Handler[Cat], as a Handler[Animal] must also handle cats.

A contravariant type parameter cannot appear in covariant (output) position. The following example will not compile as we are asserting that a Contra[Animal] <: Contra[Cat], however a Contra[Animal] has def produce: Animal which is not guaranteed to produce cats as required by Contra[Cat]!

trait Contra[-A] {
 def handle(a: A): Unit
 def produce: A

Beware however: for the purposes of overloading resolution, contravariance also counterintuitively inverts the specificity of a type on the contravariant type parameter - Handler[Animal] is considered to be "more specific" than Handler[Cat].

As it is not possible to overload methods on type parameters, this behavior generally only becomes problematic when resolving implicit arguments. In the following example ofCat will never be used, as the return type of ofAnimal is more specific:

implicit def ofAnimal: Handler[Animal] = ???
implicit def ofCat: Handler[Cat] = ???
implicitly[Handler[Cat]].handle(new Cat)

This behavior is currently slated to change in dotty, and is why (as an example) scala.math.Ordering is invariant on its type parameter T. One workaround is to make your typeclass invariant, and type-parametrize the implicit definition in the event that you want it to apply to subclasses of a given type:

trait Person
object Person {
 implicit def ordering[A <: Person]: Ordering[A] = ???


In this page (written and validated by ) you learned about Scala Type Variance . What's Next? If you are interested in completing Scala tutorial, your next topic will be learning about: Scala Type level Programming.

Incorrect info or code snippet? We take very seriously the accuracy of the information provided on our website. We also make sure to test all snippets and examples provided for each section. If you find any incorrect information, please send us an email about the issue:

Share On:

Mockstacks was launched to help beginners learn programming languages; the site is optimized with no Ads as, Ads might slow down the performance. We also don't track any personal information; we also don't collect any kind of data unless the user provided us a corrected information. Almost all examples have been tested. Tutorials, references, and examples are constantly reviewed to avoid errors, but we cannot warrant full correctness of all content. By using, you agree to have read and accepted our terms of use, cookies and privacy policy.