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.