Understanding the `out` Keyword in Kotlin Generics

By the end of this page, you will understand what out means in Kotlin generics, why it is used for covariance, and how it affects what a class or function can safely do with a type parameter. You will also see practical examples and common mistakes beginners make when reading or writing out T.

Kotlin's out keyword is used in generics to say that a type parameter is only produced and not consumed.

In simple terms:

• out T means: "This generic type gives you values of type T"
• It should not accept values of type T as input in unsafe ways
• This makes the type covariant

Why this matters

Suppose Cat is a subtype of Animal.

If a generic type only produces values, then a Producer<Cat> can safely be used where a Producer<Animal> is expected, because every Cat is also an Animal.

That is exactly what out allows.

The core idea

class Box<out T>(private val value: T) {
    fun get(): T = value
}

Here, Box<out T> means:

Think of out as a vending machine.

• A vending machine gives items out
• You can take items from it
• But you do not put random items back into it

If a machine says it gives out Cat, then it is safe to treat it as a machine that gives out Animal, because every cat is an animal.

So:

• out = output only
• safe to read from
• not safe to write into

A short memory trick:

• out -> producer
• in -> consumer

Another way to remember it:

• Producer = out
• Consumer = in

This is often called the PECS idea from generics:

• Producer Extends -> like out
• Consumer Super -> like in

Basic syntax

class Producer<out T>(private val item: T) {
    fun produce(): T = item
}

Here, T is marked with out, so Producer is only allowed to expose T as output.

Example with animals

open class Animal {
    fun speak() = println("animal sound")
}

class Cat : Animal()

class Cage<out T>(private val animal: T) {
    fun getAnimal(): T = animal
}

fun main() {
     catCage: Cage<Cat> = Cage(Cat())
     animalCage: Cage<Animal> = catCage

     animal = animalCage.getAnimal()
    animal.speak()
}

Consider this example:

open class Animal
class Cat : Animal()

class Source<out T>(private val value: T) {
    fun get(): T = value
}

fun main() {
    val catSource: Source<Cat> = Source(Cat())
    val animalSource: Source<Animal> = catSource
    val animal: Animal = animalSource.get()
    println(animal)
}

Step by step

1. Animal is the parent type

open class Animal
class Cat : Animal()

• Cat inherits from Animal
• So every Cat is also an

out is useful when a type is mainly a source of values.

Common use cases

Read-only collections

fun printAnimals(animals: List<Animal>) {
    for (animal in animals) {
        println(animal)
    }
}

Because List is covariant, you can pass List<Cat> to a function expecting List<Animal>.

API response wrappers

sealed class Result<out T> {
    data class Success<T>(val value: T) : Result<T>()
    data class Error(val message: String) : Result<Nothing>()
}

A Result<Cat> can be used where Result<Animal> is expected if the result only carries output data.

In real projects, developers use out when designing APIs that are meant to be read-only or producer-oriented.

Common patterns

Read-only interfaces

A mutable class may have internal state, but the public interface exposes only output operations.

interface ReadOnlyBox<out T> {
    fun get(): T
}

This makes the API more flexible and safer.

Return-type wrappers

Wrappers like Result<T>, Response<T>, or Resource<T> often use out because callers mostly read the wrapped value.

Guarding against invalid writes

If a type should not accept outside values, marking it as out communicates that clearly in the type system.

Safer function parameters

A function that only reads from a generic source can accept covariant types more easily.

fun logAnimals {
    println(source.())
}

1. Thinking out means "outside"

It does not mean scope or visibility. It refers to the direction of type usage.

• out = values go out of the generic type
• in = values go into the generic type

2. Trying to use T as input in an out class

Broken example:

class Box<out T> {
    fun put(item: T) {
        // Error
    }
}

Why it fails:

• item: T is an input position
• out T only allows output positions

3. Assuming MutableList<Cat> can become MutableList<Animal>

This is unsafe.

val cats: MutableList<Cat> = mutableListOf(Cat())

out vs

Quick rules

• out T means the generic type produces T
• out makes the type parameter covariant
• You can return T
• You should not accept T in input positions

Safe idea

interface Source<out T> {
    fun get(): T
}

Unsafe idea

interface Box<out T> {
    fun set(value: T) // Not allowed
}

Assignment rule

If Cat : Animal, then with out:

Source<Cat> -> Source<Animal>

Memory trick

What does out mean in Kotlin?

out marks a generic type parameter as covariant. It means the type is used for output only, so the generic type can safely produce values of that type.

Why is List declared with out in Kotlin?

Because a read-only list only provides items. It does not allow adding new ones, so covariance is safe.

What is the difference between out and in in Kotlin?

• out is for producers
• in is for consumers

Use out when values come from the type, and in when values go into the type.

Can I use a type parameter with both input and output if it is marked out?

No. If a type parameter is marked out, Kotlin restricts it from being used in unsafe input positions.

Is out the same as Java extends in generics?

It is similar to Java's ? extends T in many cases. Both express covariance.

• Generics — out is part of Kotlin's generic type system.
• Covariance — out is Kotlin's way of expressing covariance.
• Contravariance — the opposite idea, expressed with in.
• Invariant types — types with no in or out, often used for mutable structures.
• List vs MutableList in Kotlin — a practical example of covariance versus invariance.
• Type projections — useful when you apply out at the usage site, such as Array<out Any>.
• Subtyping — understanding parent and child types helps explain why out is safe.
• Kotlin collections — many collection APIs demonstrate variance in practice.