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.

Practice

1. What does the in keyword mean when used in Kotlin generics?

easy

A. It marks a generic type as contravariant, allowing it to accept supertypes safely.

B. It marks a generic type as covariant, allowing it to produce subtypes safely.

C. It restricts a generic type to only accept exact types, no subtypes or supertypes.

D. It means the generic type can be used both as input and output without restrictions.

Solution

1. Step 1: Understand variance keywords in Kotlin generics

   Kotlin uses in for contravariance and out for covariance.

2. Step 2: Identify the meaning of in

   in means the generic type can accept supertypes safely as input but cannot produce output of that type.

3. Final Answer:

   It marks a generic type as contravariant, allowing it to accept supertypes safely. -> Option A

4. Quick Check:

   in = contravariant = accept supertypes [OK]

Hint: Remember: 'in' means input only, contravariant [OK]

Common Mistakes:

• Confusing 'in' with 'out' variance
• Thinking 'in' allows output of the generic type
• Assuming 'in' restricts to exact types only

2. Which of the following is the correct syntax to declare a contravariant generic interface in Kotlin?

easy

A. interface Consumer { fun consume(item: T) }

B. interface Consumer { fun consume(item: T) }

C. interface Consumer<T> { fun consume(item: in T) }

D. interface Consumer<T> { fun consume(item: out T) }

Solution

1. Step 1: Recall syntax for contravariant generic declaration

   Contravariance uses in before the generic type parameter in the interface declaration.

2. Step 2: Check method parameter usage

   Method parameter can use the generic type normally; the variance is declared at the interface level.

3. Final Answer:

   interface Consumer { fun consume(item: T) } -> Option B

4. Quick Check:

   Contravariant syntax = in before T [OK]

Hint: Use 'in' before generic type name for contravariance [OK]

Common Mistakes:

• Using 'out' instead of 'in' for contravariance
• Placing 'in' inside method parameters incorrectly
• Omitting variance keyword entirely

3. Consider the following Kotlin code:

interface Consumer {
    fun consume(item: T)
}

fun feed(consumer: Consumer<Number>) {
    consumer.consume(42)
}

val intConsumer: Consumer<Int> = object : Consumer<Int> {
    override fun consume(item: Int) {
        println("Consumed: $item")
    }
}

feed(intConsumer)

What will happen when this code runs?

medium

A. Prints 'Consumed: 42' successfully.

B. Runtime error due to type mismatch.

C. Compilation error because Consumer<Int> is not a subtype of Consumer<Number>.

D. Prints nothing because consume is never called.

Solution

1. Step 1: Understand contravariance direction

   Contravariance means Consumer<Supertype> can accept Consumer<Subtype>, not the other way around.

2. Step 2: Analyze the call feed(intConsumer)

   feed expects Consumer<Number>, but intConsumer is Consumer<Int>. Since Int is subtype of Number, Consumer<Int> is not subtype of Consumer<Number> when contravariant.

3. Final Answer:

   Compilation error because Consumer<Int> is not a subtype of Consumer<Number>. -> Option C

4. Quick Check:

   Contravariance reverses subtype relation [OK]

Hint: Contravariant: Consumer<Super> accepts Consumer<Sub>, not vice versa [OK]

Common Mistakes:

• Assuming Consumer<Int> can be passed where Consumer<Number> is expected
• Confusing covariance and contravariance
• Expecting runtime error instead of compile-time error

4. Given this Kotlin code snippet:

interface Consumer {
    fun consume(item: T)
}

fun process(consumer: Consumer<Number>) {
    consumer.consume(3.14)
}

val doubleConsumer: Consumer<Double> = object : Consumer<Double> {
    override fun consume(item: Double) {
        println("Consumed double: $item")
    }
}

process(doubleConsumer)

Why does this code cause a compilation error?

medium

A. Because Consumer<Double> cannot be passed where Consumer<Number> is expected due to contravariance.

B. Because Double is not a subtype of Number.

C. Because consume method parameter type is incorrect.

D. Because process function tries to consume an Int instead of a Double.

Solution

1. Step 1: Recall contravariance subtype rules

   For Consumer, Consumer<Supertype> can accept Consumer<Subtype>, not the reverse.

2. Step 2: Check the types in the call

   process expects Consumer<Number>, but doubleConsumer is Consumer<Double>. Double is subtype of Number, so Consumer<Double> is not subtype of Consumer<Number>.

3. Final Answer:

   Because Consumer<Double> cannot be passed where Consumer<Number> is expected due to contravariance. -> Option A

4. Quick Check:

   Contravariance reverses subtype relation [OK]

Hint: Contravariant types reverse subtype order [OK]

Common Mistakes:

• Thinking Double is not subtype of Number
• Confusing method parameter types
• Assuming runtime error instead of compile-time

5. You want to create a function that accepts any consumer that can consume Number or any of its supertypes safely. Which declaration correctly uses contravariance to allow this flexibility?

interface Consumer {
    fun consume(item: T)
}

fun acceptConsumer(consumer: Consumer<___>) {
    consumer.consume(100)
}

hard

A. Nothing

B. Number

C. Int

D. Any

Solution

1. Step 1: Understand contravariance usage

   Contravariance allows passing a consumer of a supertype to a function expecting a consumer of a subtype.

2. Step 2: Determine the correct generic type

   To accept consumers that can consume Number or any supertype safely (i.e., Consumer<Number> and Consumer<Any>), use Any as the generic parameter.

3. Final Answer:

   Any -> Option D

4. Quick Check:

   Contravariant consumer accepts supertypes [OK]

Hint: Use Any (a supertype of Number) for contravariant parameter to accept consumers of Number or its supertypes [OK]

Common Mistakes:

• Using supertype like Any, which only accepts Consumer<Any>
• Using subtype like Int
• Using Nothing which is subtype of all types