In variance (contravariance) in Kotlin - Step-by-Step Execution

Concept Flow - In variance (contravariance)

Start: Function expects Consumer<T>

↓

Use Consumer<in T> to accept T or its supertypes

↓

Pass Consumer<SuperType> where Consumer<T> expected

↓

Function calls consumer.accept(T)

↓

Consumer handles T or subtype safely

↓

End

Shows how contravariance allows passing a consumer of a supertype where a consumer of a subtype is expected, enabling safe input.

Execution Sample

Kotlin

interface Consumer<in T> {
    fun accept(item: T)
}

fun feedConsumer(consumer: Consumer<String>) {
    consumer.accept("Hello")
}

Defines a Consumer interface with contravariant type T and a function that feeds a String to the consumer.

Execution Table

Step	Action	Type of consumer passed	accept() argument type	Result
1	Call feedConsumer with Consumer<Any>	Consumer<Any>	String	Allowed: Consumer<Any> accepts String
2	Inside feedConsumer, call consumer.accept("Hello")	Consumer<Any>	String	Prints or processes "Hello"
3	Call feedConsumer with Consumer<String>	Consumer<String>	String	Allowed: exact match
4	Inside feedConsumer, call consumer.accept("Hello")	Consumer<String>	String	Prints or processes "Hello"
5	Call feedConsumer with Consumer<Int>	Consumer<Int>	String	Error: Consumer<Int> cannot accept String
6	Execution stops due to type mismatch	-	-	-

💡 Cannot pass Consumer<Int> where Consumer<String> expected because Int is not a supertype of String

Variable Tracker

Variable	Start	After Step 1	After Step 3	After Step 5
consumer	undefined	Consumer<Any>	Consumer<String>	Consumer<Int> (invalid)
accept argument	undefined	"Hello" (String)	"Hello" (String)	Type mismatch

Key Moments - 2 Insights

Why can we pass Consumer<Any> to a function expecting Consumer<String>?

Because Consumer is declared with 'in' (contravariant), it can accept supertypes of String, so Consumer<Any> can safely consume Strings (see execution_table rows 1 and 2).

Why can't we pass Consumer<Int> to feedConsumer expecting Consumer<String>?

Consumer<Int> expects Int inputs, but feedConsumer passes a String, causing a type mismatch (see execution_table row 5). Contravariance only allows supertypes, not unrelated or subtypes.

Visual Quiz - 3 Questions

Look at the execution_table, what type of consumer is allowed to be passed to feedConsumer?

A Consumer<Double>

B Consumer<Int>

C Consumer<Any>

D Consumer<List<String>>

💡 Hint

Check execution_table rows 1 and 5 to see which consumer types are accepted or rejected.

At which step does the execution stop due to a type mismatch?

A Step 5

B Step 4

C Step 2

D Step 3

💡 Hint

Look at execution_table row 5 where Consumer is passed and causes an error.

If we remove 'in' from Consumer<T>, what happens when passing Consumer<Any> to feedConsumer?

A It works the same

B It causes a type error

C Consumer<Any> becomes Consumer<String>

D The function accepts any consumer

💡 Hint

Contravariance ('in') allows passing supertypes; removing it disables this flexibility (see concept_flow).

Concept Snapshot

In variance (contravariance) in Kotlin uses 'in' keyword.
It allows a generic type Consumer<in T> to accept T or any supertype.
This means you can pass Consumer<Any> where Consumer<String> is expected.
Useful for input-only generic types.
Contravariance ensures type safety when consuming values.

Full Transcript

This visual trace shows how Kotlin's in variance (contravariance) works with a Consumer interface. The Consumer interface is declared with 'in T', meaning it can accept T or any supertype of T. The feedConsumer function expects a Consumer<String>. Thanks to contravariance, you can pass a Consumer<Any> safely because Any is a supertype of String. The execution table shows steps where Consumer<Any> and Consumer<String> are accepted, but Consumer<Int> is rejected because Int is not a supertype of String. Variable tracking shows how the consumer variable changes type across calls. Key moments clarify why contravariance allows supertypes but not unrelated types. The quiz tests understanding of allowed types, error steps, and the effect of removing 'in'. This helps beginners see how contravariance enables safe input flexibility in Kotlin generics.