In variance (contravariance) in Kotlin

Introduction

In Kotlin, contravariance helps you use a more general type where a more specific type is expected. It makes your code flexible and safe when working with types that consume data.

When you want to pass a function or class that accepts a more general type than the one expected.

When you have a consumer (like a function parameter) that only takes input but never produces output.

When working with generic types that only consume values, such as comparators or event handlers.

When you want to avoid type errors by allowing a supertype to be used where a subtype is expected.

Syntax

Kotlin

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

The in keyword before the generic type T marks it as contravariant.

Contravariant types can only be used as input (parameters), not as output (return types).

Examples

This interface consumes items of type T. The in keyword means it can accept T or any supertype of T.

Kotlin

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

This function accepts a consumer of Int. Thanks to contravariance, you can pass a Consumer<Number> safely.

Kotlin

fun feedConsumer(consumer: Consumer<Int>) {
    consumer.consume(42)
    consumer.consume(100)
}

Because of contravariance, a Consumer<Number> can be assigned to a Consumer<Int> variable.

Kotlin

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

val intConsumer: Consumer<Int> = numberConsumer

Sample Program

This program shows contravariance by assigning a Consumer to a Consumer variable. The feedConsumer function calls consume with different Int types.

Kotlin

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

class NumberConsumer : Consumer<Number> {
    override fun consume(item: Number) {
        println("Consumed Number: $item")
    }
}

fun feedConsumer(consumer: Consumer<Int>) {
    consumer.consume(10)
    consumer.consume(20)
}

fun main() {
    val numberConsumer = NumberConsumer()
    // Contravariance allows this assignment
    val intConsumer: Consumer<Int> = numberConsumer
    feedConsumer(intConsumer)
}

Important Notes

Contravariant types cannot be returned from functions because they are only safe as inputs.

Use in only when the generic type is used as a function parameter, never as a return type.

Contravariance is the opposite of covariance, which uses out and allows returning types.

Summary

Use in to mark a generic type as contravariant, meaning it can accept supertypes safely.

Contravariance is useful for consumers that only take input and never produce output.

It helps make your Kotlin code more flexible and type-safe when working with generic types.

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