How do Kotlin's `out` and `in` variance modifiers map onto Java's `? extends` and `? super` wildcards, and how does this relate to the PECS rule?
answer
- out = producer = ? extends
- in = consumer = ? super
- PECS = Producer Extends, Consumer Super
- covariant reads, contravariant writes
- copy(from: out, to: in)
basics
~10 sout means a type only produces values, like Java's ? extends (a producer). in means a type only consumes values, like Java's ? super (a consumer). PECS: Producer Extends, Consumer Super.
solid answer
~40 sKotlin uses declaration-site and use-site variance instead of Java's wildcard-only model. `out T` (covariant, producer) corresponds to Java's `? extends T`: you can read `T` out but not pass it in. `in T` (contravariant, consumer) corresponds to `? super T`: you can pass `T` in but only read `Any?` out. This is exactly Josh Bloch's PECS rule — Producer-Extends, Consumer-Super. Kotlin's `MutableList<out Number>` compiles to `List<? extends Number>`; `MutableList<in Number>` compiles to `List<? super Number>`. The key insight is that Kotlin lets you declare variance once on the class (`interface List<out E>`) so callers rarely need wildcards, whereas Java forces the wildcard at every use site.
code
kotlin · 7 linesfun <T> copy(from: Array<out T>, to: Array<in T>) {
for (i in from.indices) to[i] = from[i] // read producer, write consumer
}
val ints: Array<Int> = arrayOf(1, 2)
val anys: Array<Any> = arrayOfNulls<Any>(2)
copy(ints, anys) // from: Array<out Int>, to: Array<in Int> — both OKgo deeper
Recites the out=extends / in=super mapping and the PECS mnemonic with a simple example.
Explains WHY producers are covariant and consumers contravariant, and writes a correct copy signature.
Connects declaration-site vs use-site variance and predicts the generated Java wildcard for a given Kotlin signature.
Discusses API design tradeoffs of where to place variance and how it affects cross-language consumers and source compatibility.
## The problem variance solves Generics are *invariant* by default: `List<String>` is NOT a subtype of `List<Any>`, even though `String` is a subtype of `Any`. Variance modifiers selectively relax this. ## Covariance — `out` / `? extends` A type is a **producer** if it only *returns* (produces) `T` and never *accepts* it as a parameter. - Kotlin: `out T` (declaration-site) or `Source<out T>` (use-site projection). - Java equivalent: `? extends T`. - Rule: if it only produces `T`, then `Producer<Cat>` can safely be used as `Producer<Animal>` (you'll only ever pull out things that are at least `Animal`). ```kotlin interface Source<out T> { fun next(): T } // producer val cats: Source<Cat> = ... val animals: Source<Animal> = cats // OK: covariant ``` In Java the same thing requires a wildcard at the use site: `Source<? extends Animal>`. ## Contravariance — `in` / `? super` A type is a **consumer** if it only *accepts* `T` as a parameter and never returns it. - Kotlin: `in T` or `Sink<in T>`. - Java equivalent: `? super T`. - Rule: `Sink<Animal>` can be used as `Sink<Cat>` — anything that consumes `Animal` can certainly consume `Cat`. ```kotlin interface Sink<in T> { fun put(item: T) } // consumer val animalSink: Sink<Animal> = ... val catSink: Sink<Cat> = animalSink // OK: contravariant ``` ## PECS — the mnemonic Josh Bloch (Effective Java) coined **PECS**: **P**roducer **E**xtends, **C**onsumer **S**uper. When you read FROM a structure, use `extends` (`out`); when you write TO it, use `super` (`in`). Kotlin's `copy` signature is the canonical example: ```kotlin fun <T> copy(from: Array<out T>, to: Array<in T>) { /* read from, write to */ } ``` `from` is a producer (`out`), `to` is a consumer (`in`). This maps directly to Java's `<T> void copy(T[] src /* ? extends T */, T[] dst /* ? super T */)`. ## Why the mapping matters Kotlin compiles `out`/`in` to real Java wildcards in bytecode, so the two languages interoperate seamlessly. Understanding the correspondence lets you predict the generated Java signature and write APIs that read naturally from both sides. | Kotlin | Java | Role | |--------|------|------| | `out T` | `? extends T` | producer (read) | | `in T` | `? super T` | consumer (write) | | `T` (invariant) | `T` | both |
- Why can't you call `put(item: T)` on a `Source<out T>`?Because `out` forbids `T` in `in` (parameter) positions; allowing writes would break covariance safety, so the compiler rejects it.
- What is `out`/`in` called formally?`out` is covariance, `in` is contravariance; declaring them on the class is declaration-site variance.
A vending machine is out (it only dispenses); a recycling bin is in (it only accepts).
saying these in an interview costs you the question
- Saying `out` means 'output type' generally rather than a producer/covariant position
- Mixing up PECS — claiming Producer Super
- Thinking Kotlin has no equivalent to Java wildcards
- Believing `in T` lets you read `T` back out as `T` (you only get `Any?`)