Kotlin in Action devotes an entire chapter to generics and variance. The vocabulary — `in`, `out`, `*` — looks small but unlocks the most subtle parts of the type system. Without variance you can't safely express `List` as a `List`. ## Basic generics (review) ```kotlin fun singleton(x: T): List = listOf(x) class Box(val value: T) ``` T is a type parameter. Multiple bounded constraints with `where`: ```kotlin fun max(items: List): T? where T : Comparable { return items.maxOrNull() } ``` ## The variance problem Suppose `Cat : Animal`. Is `List` a `List`? ```kotlin open class Animal class Cat : Animal() fun feedAll(list: List) { /* ... */ } val cats: List = listOf(Cat(), Cat()) feedAll(cats) // does this work? ``` In Kotlin, **YES** — because `List` is **covariant** in T (declared with `out`). In Java, NO — `List` is invariant by default. The issue: if MutableList were a MutableList, you could `add(Dog())` to it — heap pollution. So mutation breaks subtyping. ## out — covariance ("producer") `out T` says T is only PRODUCED (returned), never CONSUMED (taken as input): ```kotlin interface Source { fun get(): T // produces T — OK // fun set(x: T) // would CONSUME — not allowed with out } val intSource: Source = ... val anyySource: Source = intSource // OK — covariant ``` Kotlin's read-only `List` is declared this way — you can read but not write, so subtyping is safe. ## in — contravariance ("consumer") `in T` says T is only CONSUMED, never PRODUCED: ```kotlin interface Sink { fun put(x: T) // consumes T — OK // fun get(): T // would PRODUCE — not allowed with in } val anySink: Sink = ... val intSink: Sink = anySink // OK — contravariant (reversed) ``` If you can dump any Animal into a sink, you can certainly dump a Cat. Subtyping is reversed. ## The PECS rule (from Java, applies here) **Producer Extends, Consumer Super.** In Kotlin: **out for producers, in for consumers.** ```kotlin fun copy(source: Source, sink: Sink) { sink.put(source.get()) } ``` Source produces (out). Sink consumes (in). Now `copy(catSource, anySink)` works because of the variance. ## Use-site variance with `in` / `out` If you can't change a class's declaration, you can specify variance at the USE site: ```kotlin fun copyAll(source: List, dest: MutableList) { for (x in source) dest.add(x) } ``` Like Java's `? extends` and `? super`. Less common in Kotlin because most stdlib types already declare variance correctly. ## Star projection: <*> "I don't know or care about T": ```kotlin fun printAll(list: List<*>) { for (x in list) println(x) } ``` Like Java's `List`. Reads-only as `Any?`. Useful for utility code that doesn't depend on the element type. ## reified — runtime access to T Normally generics are erased — `T::class` doesn't compile. With `inline + reified`, T survives: ```kotlin inline fun Any.castOrNull(): T? = this as? T val x: Any = "hi" val s: String? = x.castOrNull() // works ``` ## Common mistakes - **Using out where you write to T** — compile error. out only allows reading. - **Misreading variance** — in/out describe the role of T in the API, not how you use the value. - **Forgetting on read-only collection types** — Kotlin's stdlib does this for you; rolling your own, remember to declare variance. - **Star projection where you need a real T** — `List<*>` reads as `Any?`. If you need typed reads, use a generic function with bound T. - **inline everything** — bloat. Inline only when reified is needed or the function is small + hot.

Kotlin Advanced

Curriculum