Tag: declaration-site

Contravariance

Understanding how contravariance affects the ability to use Generics in Kotlin.

fun main() {
    val roseTender = object: FlowerCare2<Rose2> {
        override fun prune(flower: Rose2) {
            println("I'm pruning a rose!")
        }
    }

    val daffodilTender = object: FlowerCare2<Daffodil2> {
        override fun prune(flower: Daffodil2) {
            println("I'm pruning a daffodil!")
        }
    }

    val roseGarden = Garden2(listOf(Rose2("Rosemary"), Rose2("Rosie")), roseTender)
    println(roseGarden.javaClass)

    val daffodilGarden = Garden2(listOf(Daffodil2(), Daffodil2(), Daffodil2()), daffodilTender)
    println(roseGarden.javaClass)

    roseGarden.tendFlower(0)

    daffodilGarden.tendFlower(2) // This is rather repetitive. We have to create Gardens and call tendFlower, but roseTender and daffodilTender are doing the same thing

    val flowerTender = object : FlowerCare2<Flower2> { // Create a generic flowerTender that can handle any type of Flower2
        override fun prune(flower: Flower2) {
            println("I'm tending a specifically-named ${flower.name}!")
        }
    }

    val roseGarden2 = Garden2(listOf(Rose2("Rosemary"), Rose2("Rosie")), flowerTender) // Won't work without adding 'in' to FlowerCare2 class, as expects FlowerCare2<Rose2>. We need <T> matching to be more relaxed.
    // Covariance preserves the subtyping. Contravariance is the opposite - starting with subclass and wanting to accept superclasses.
    // Comes at a price. We can only write them and not read from them. Cannot use them as return types from functions.

    roseGarden2.tendFlower(1)

}

class Garden2<T: Flower2>(val flowers: List<T>, val flowerCare: FlowerCare2<T>) {
    fun pickFlower(i: Int) = flowers[i]
    fun tendFlower(i: Int) {
        flowerCare.prune(flowers[i])
    }
}

open class Flower2(val name: String) {

}

class Rose2(val roseName: String): Flower2(roseName) {

}

class Daffodil2: Flower2("Daffodil") {

}

interface FlowerCare2<in T> { // Made contravariant by 'in' keyword. Will accept T or any superclass of.
  // As it is done in the declaration is known as 'declaration-site variance'. Java only has 'use-site variance' (see post of same name).
    fun prune(flower: T)
//    fun pick(): T // Cannot return this Generic as it is now contravariant
}

 

Covariance in Kotlin

Understanding how covariance affects the ability to use Generics in Kotlin.

fun main() {
    val shortList: List<Short> = listOf(1, 2, 3, 4, 5)
    convertToInt5(shortList) // All fine here

    val shortList2: MutableList<Short> = mutableListOf(1, 2, 3, 4, 5)
//    convertToInt6(shortList2) // Not allowed - type mismatch. But why? Surely Short is a sub-type (N.B. NOT a sub-class) of Number? And why did it work with an immutable List but not a mutable one?
    // List is a class, but List<String> is a type. Although we rationally would assume that it should accept a List<Short> if it accepts a List<Number>, it is not the same as a subclass.
    // So we want List<Short> to be a subtype of List<Number>. This is where the covariant keyword comes in - it preserves subtyping when working with Generics.
    // When looking at the Collections interface we can see that immutable Collections are covariant (<out E>) whereas mutable Collections are not - hence why the immutable List worked.

}

fun convertToInt5(collection: List<Number>) {
    for (num in collection) {
        println("${num.toInt()}")
    }
}

fun convertToInt6(collection: MutableList<Number>) {
    for (num in collection) {
        println("${num.toInt()}")
    }
}

fun tendGarden(roseGarden: Garden<Rose>) {
    waterGarden(roseGarden) // By default wants a garden<Flower> and we are passing it a Garden<Rose>, even though Rose is a subclass of Flower
    // This is because the Garden class is invariant, so will only accept Garden<Flower>. When we add 'out' to the Garden class this is resolved, but at a price:
    // We're now restricted and can only use the covariant class in the 'out' position, like an immutable Collection (can read but not add)
    // Function parameters are considered in the 'in' position (invariant) and the function return type is in the 'out' position (covariant)
    // Constructor parameters don't have 'in' or 'out' positions so you can always pass in a covariant class. No danger in this situation.
    // But if you pass in a var of type <T> to a constructor, it can't be covariant because setter needs to be generated. It would need to be invariant or declared as a val.
    // If you have a private function or property you don't need to worry about 'in' and 'out' - they're safe inside the class.
}

fun waterGarden(garden: Garden<Flower>) {

}

open class Flower {

}

class Rose: Flower() {

}

class Garden<out T: Flower> { // We can have a garden of daisies, daffodils etc. 'Out' keyword added to make it covariant.
  // As is done within the declaration is known as 'declaration-site variance'. Java only has 'use-site variance' (see post of same name).

    val flowers: List<T> = listOf()

    fun pickFlower(i: Int): T = flowers[i] // Pick the ith flower. Being overly verbose for readability
//    fun plantFlower(flower: T) {} // Not allowed as T is in 'out' position, not suitable as a parameter. This is to stop e.g. a daisy being planted in a rose garden.
    // This applies to member functions of the covariant class only.
}

// If you are ABSOLUTELY sure you will not pass an invalid type to your invariant class you can suppress the compiler warning by using the <@UnsafeVariance T> annotation.