In variance (contravariance) in Kotlin - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to declare a contravariant generic interface using the correct keyword.

Kotlin

interface Consumer<[1] T> {
    fun consume(item: T)
}

Drag options to blanks, or click blank then click option'

Avar

Bin

Cout

Dval

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'out' instead of 'in' for contravariance.

Using 'var' or 'val' which are not variance keywords.

In Kotlin, in is used to declare contravariance, allowing the generic type to be used only as input.

2fill in blank

medium

Complete the function parameter type to accept a contravariant generic Consumer.

Kotlin

fun feed(consumer: Consumer<[1] Animal>) {
    consumer.consume(Dog())
}

Drag options to blanks, or click blank then click option'

Ain

Bout

Cvar

Dval

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'out' which is for covariance, not contravariance.

Omitting the variance keyword causing type errors.

The in keyword allows the Consumer to accept subtypes of Animal, enabling contravariance.

3fill in blank

hard

Fix the error in the function call by adding the correct variance modifier.

Kotlin

val consumer: Consumer<[1] Dog> = object : Consumer<Animal> {
    override fun consume(item: Animal) {
        println("Consumed: $item")
    }
}

Drag options to blanks, or click blank then click option'

Ain

Bout

Cvar

Dval

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'out' which causes type mismatch.

Not using any variance modifier causing compilation error.

Declaring Consumer allows assigning a Consumer to it because of contravariance.

4fill in blank

hard

Complete the code to create a contravariant function type parameter and call it correctly.

Kotlin

fun process(consumer: ([1] String) -> Unit) {
    consumer("Hello")
}

process -> { println(it) }

Drag options to blanks, or click blank then click option'

Ain

Bout

C->

D->>

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'out' instead of 'in' for the input parameter.

Using '->>' which is invalid syntax.

The function parameter uses in for contravariance on input type, and the arrow -> separates parameter and return type.

5fill in blank

hard

Fill all three blanks to declare a contravariant generic class, implement it, and use it.

Kotlin

class Printer<[1] T> {
    fun print(item: T) {
        println(item)
    }
}

val printer: Printer<[2] Any> = Printer<[3] String>()

Drag options to blanks, or click blank then click option'

Ain

Bout

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'out' which is covariance, not contravariance.

Mixing variance modifiers causing type mismatch.

Using in declares contravariance, allowing Printer to be assigned to Printer.

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