Amol Pawar

Kotlin’s type system offers robust features for managing generics, including the concepts of covariance and contravariance. A common question among developers is how constructor parameters influence variance in Kotlin. Let’s explore this topic in a straightforward and approachable manner.

Generics and Variance in Kotlin

Before diving into the Role of Constructor Parameters in Kotlin Variance, it’s essential to grasp the basics of generics and variance:

Generics allow classes and functions to operate on different data types while maintaining type safety.

Variance defines how subtyping between more complex types relates to subtyping between their component types. In Kotlin, this is managed using the in and out modifiers.

• The out modifier indicates that a type parameter is covariant, meaning the class can produce values of that type but not consume them.
• The in modifier denotes contravariance, where the class can consume values of that type but not produce them.

The Role of Constructor Parameters

In Kotlin, constructor parameters are not considered to be in the “in” or “out” position when it comes to variance. This means that even if a type parameter is declared as “out,” you can still use it in a constructor parameter declaration without any restrictions.

For example:

class Herd<out T: Animal>(vararg animals: T) { ... }

The type parameter T is declared as “out,” but it can still be used in the constructor parameter vararg animals: T without any issues. The variance protection is not applicable to the constructor because it is not a method that can be called later, so there are no potentially dangerous method calls that need to be restricted.

However, if you use the val or var keyword with a constructor parameter, it declares a property with a getter and setter (if the property is mutable). In this case, the type parameter T is used in the “out” position for a read-only property and in both “out” and “in” positions for a mutable property.

For example:

class Herd<T: Animal>(var leadAnimal: T, vararg animals: T) { ... }

Here, the type parameter T cannot be marked as “out” because the class contains a setter for the leadAnimal property, which uses T in the “in” position. The presence of a setter makes it necessary to consider both “out” and “in” positions for the type parameter.

It’s important to note that the position rules for variance in Kotlin only apply to the externally visible API of a class, such as public, protected, and internal members. Parameters of private methods are not subject to the “in” or “out” position rules. The variance rules are in place to protect a class from misuse by external clients and do not affect the implementation of the class itself.

For instance:

class Herd<out T: Animal>(private var leadAnimal: T, vararg animals: T) { ... }

In this case, the Herd class can safely be made covariant on T because the leadAnimal property has been made private. The private visibility means that the property is not accessible from external clients, so the variance rules for the public API do not apply.

Conclusion

In Kotlin, constructor parameters are neutral regarding variance. This neutrality ensures that you can use generic types in constructors without affecting the covariant or contravariant nature of your classes. Understanding this aspect of Kotlin’s type system enables you to write more robust and flexible generic classes.

By keeping constructor parameters and variance separate, Kotlin provides a type-safe environment that supports both flexibility and clarity in generic programming.

Generics in Kotlin can seem complex at first, but once you understand their power, they make your code more flexible and reusable. In this blog, we’ll break down generics in a simple way, focusing on generic functions and properties and best practices.

What Are Generics in Kotlin?

Generics allow you to write code that works with different data types without sacrificing type safety. Instead of specifying an exact type, you define a placeholder type that gets replaced with a real type at runtime.

For example, consider a function that prints any type of element. Instead of writing separate functions for Int, String, and other types, you can use generics to make it work for any type.

without generics, you might write:

fun printInt(value: Int) {
    println(value)
}

fun printString(value: String) {
    println(value)
}

With generics, you can simplify this:

fun <T> printValue(value: T) {
    println(value)
}

Now, printValue works with any type!

Generic Functions in Kotlin

A generic function uses a type parameter to make it more flexible. The type parameter is placed inside angle brackets (<>) before the function’s parameter list.

A Simple Generic Function

fun <T> printItem(item: T) {
    println(item)
}

fun main() {
    printItem(42)       // Works with Int
    printItem("Hello")  // Works with String
    printItem(3.14)     // Works with Double
}

• <T> is the type parameter.
• T is used as the parameter type inside the function.
• The function can now accept any type, making it more reusable.

Generic Function with Multiple Parameters

fun <T, U> pairItems(first: T, second: U): Pair<T, U> {
    return Pair(first, second)
}

fun main() {
    val pair = pairItems("Hello", 100)
    println(pair) // Output: (Hello, 100)
}

Here, we define two generic types, T and U, making the function even more flexible.

Generic Properties in Kotlin

You can also use generics with properties in classes.

class Box<T>(var content: T)

fun main() {
    val intBox = Box(42)
    val stringBox = Box("Hello, Kotlin Generics!")
    
    println(intBox.content)   // Outputs: 42
    println(stringBox.content) // Outputs: Hello, Kotlin Generics!
}

Here, Box<T> is a generic class where T represents any type. This allows us to create boxes for different types without duplicating code.

Read-Only Generic Properties

If you want a read-only generic property:

class ReadOnlyBox<T>(private val content: T) {<br>    fun getContent(): T = content<br>}

Since content is private, it can only be accessed via getContent().

Best Practices

Use Meaningful Type Parameter Names: Instead of <T>, consider using <Item> or <Element> for better readability.

Prefer Read-Only Properties: If a property doesn’t need modification, keep it read-only (val) to improve safety.

Avoid Unnecessary Generics: If a function doesn’t require type flexibility, don’t use generics unnecessarily. It can make the code harder to read.

Read the full article here: [Main Article URL]

Conclusion

Kotlin’s generics allow for reusable and type-safe code. By understanding generic functions and properties, you can write cleaner and more efficient Kotlin programs. Follow best practices, use it wisely, and keep your code readable.

Now that you have a solid grasp, try using generic functions and properties in your own Kotlin projects!

Kotlin is a powerful language that puts a strong emphasis on null safety. However, when working with generics, it’s easy to accidentally allow nullability, even when you don’t intend to. If you’re wondering how to enforce non-null type parameters properly, this guide will walk you through the right approach.

Why Enforcing Non-Null Type Parameters Matters

Kotlin’s type system prevents null pointer exceptions by distinguishing between nullable and non-nullable types. However, generics (T) are nullable by default, which can lead to unintended issues if not handled correctly.

For example, consider the following generic class:

class Container<T>(val value: T)

Here, T can be any type—including nullable ones like String?. This means that Container<String?> is a valid type, even if you don’t want to allow null values.

Making type parameters non-null

In Kotlin, when you declare a generic class or function, you can substitute any type argument, including nullable types, for its type parameters. By default, a type parameter without an upper bound specified will have the upper bound of Any? which means it can accept both nullable and non-nullable types.

Let’s take an example to understand this. Consider the Processor class defined as follows:

class Processor<T> {
    fun process(value: T) {
        value?.hashCode()     // value” is nullable, so you have to use a safe call
    }
}

In the process function of this class, the parameter value is nullable, even though T itself is not marked with a question mark. This is because specific instantiations of the Processor class can use nullable types for T. For example, you can create an instance of Processor<String?> which allows nullable strings as its type argument:

val nullableStringProcessor = Processor<String?>()  // String?, which is a nullable type, is substituted for T
nullableStringProcessor.process(null)              // This code compiles fine, having “null” as the “value” argument

If you want to ensure that only non-null types can be substituted for the type parameter, you can specify a constraint or an upper bound. If the only restriction you have is nullability, you can use Any as the upper bound instead of the default Any?. Here’s an example:

class Processor<T : Any> {         // Specifying a non-“null” upper bound
    fun process(value: T) {
        value.hashCode()          // “value” of type T is now non-“null”
    }
}

In this case, the <T : Any> constraint ensures that the type T will always be a non-nullable type. If you try to use a nullable type as the type argument, like Processor<String?>(), the compiler will produce an error. The reason is that String? is not a subtype of Any (it’s a subtype of Any?, which is a less specific type):

val nullableStringProcessor = Processor<String?>()

// Error: Type argument is not within its bounds: should be subtype of 'Any'

It’s worth noting that you can make a type parameter non-null by specifying any non-null type as an upper bound, not only Any. This allows you to enforce stricter constraints based on your specific needs.

The Wrong Way: Using T : Any?

Some developers mistakenly try to restrict T by writing:

class Container<T : Any?>(val value: T)

However, this does not enforce non-nullability. The bound Any? explicitly allows both Any (non-null) and null. This approach is unnecessary since T is already nullable by default.

The Right Way: Enforcing Non-Null Type Parameters

To ensure that a type parameter is always non-null, you should use an upper bound of Any instead:

class Container<T : Any>(val value: T)

Why This Works

• The constraint T : Any ensures that T must be a non-nullable type.
• Container<String?> will not compile, preventing unintended nullability.
• You still maintain type safety and avoid potential null pointer exceptions.

Here’s a quick test:

fun main() {
    val nonNullContainer = Container("Hello") // Works fine
    val nullableContainer = Container<String?>(null) // Compilation error
}

Applying Non-Null Type Parameters in Functions

If you’re defining a function that uses generics, you can apply the same constraint:

fun <T : Any> printNonNullValue(value: T) {
    println(value)
}

This ensures that T cannot be null:

fun main() {
    printNonNullValue("Kotlin") // Works fine
    printNonNullValue(null) // Compilation error
}

Using Non-Null Type Parameters in Interfaces and Classes

You can also enforce non-nullability in interfaces:

interface Processor<T : Any> {
    fun process(value: T)
}

And in abstract classes:

abstract class AbstractHandler<T : Any> {
    abstract fun handle(value: T)
}

These patterns ensure that all implementations respect non-nullability.

Conclusion

Making type parameters non-null in Kotlin is essential for writing safer, more predictable code. Instead of leaving T nullable or mistakenly using T : Any?, enforce non-nullability using T : Any. This simple yet powerful technique helps prevent unexpected null values while maintaining the flexibility of generics.

By applying this Kotlin tip, you can improve your code’s safety and avoid common pitfalls related to nullability.