Kotlin

Kotlin, known for its concise syntax and powerful features, has gained immense popularity among developers. One of its notable features is the ability to declare kotlin inline properties. Kotlin inline properties combine the benefits of properties and inline functions, providing improved performance and better control over code structure. In this blog post, we’ll dive deep into Kotlin inline properties, covering their definition, benefits, and use cases, and providing detailed examples to solidify your understanding.

Understanding Inline Properties

An inline property is a property that is backed by an inline function. This means that when you access the property, the code of the getter function is directly inserted at the call site, similar to how inline functions work. This has significant implications for performance, as it eliminates the overhead of function calls.

What are Kotlin inline properties?

Inline properties are a Kotlin feature that allows you to improve the performance of your code by inlining the property accessors into the code that uses them. This means that the compiler will copy the body of the accessors into the call site, instead of calling them as separate functions.

Inline properties can be used for both read-only (val) and mutable (var) properties. However, they can only be used for properties that do not have a backing field.

When to use Kotlin inline properties?

Inline properties should be used when you want to improve the performance of your code by reducing the number of function calls. This is especially useful for properties that are accessed frequently or that are used in performance-critical code.

Inline properties should not be used when the property accessors are complex or when the property is not accessed frequently. In these cases, the performance benefits of inlining may not be worth the added complexity.

Declaring Kotlin Inline Properties

To declare an inline property in Kotlin, you’ll use the inline keyword before the property definition. Here’s the general syntax:

inline val propertyName: PropertyType
    get() = propertyValue

Let’s break down the code:

• inline: This keyword indicates that the property is inline, allowing its getter code to be inserted at the call site.
• val: Indicates that the property is read-only.
• propertyName: The name you give to your property.
• PropertyType: The data type of the property.
• propertyValue: The value that the property holds.

Few Simple Declarations of Kotlin inline properties

Here are some simple examples of how to use Kotlin inline properties:

// A read-only inline property
inline val foo: String
    get() = "Hello, softAai!"

// A mutable inline property
inline var bar: Int
    get() = TODO() // You need a getter function for a mutable property
    set(value) {
        // Do something with the value.
    }

// An inline property with a custom getter and setter
inline val baz: String
    get() = "This is a custom getter."
    set(value) {
        // Do something with the value.
    }

In the above code snippet:

• For the bar property, you need to provide a getter function since it’s a mutable property. In this case, I’ve used TODO() to indicate that you need to replace it with an actual getter implementation.
• The baz property is defined with a custom getter and setter. The getter provides a string value, and the setter is a placeholder where you can implement custom logic to handle the incoming value.

Use Cases for Kotlin Inline Properties

1. Simple Properties: Inline properties are ideal for cases where you have simple read-only properties that involve minimal computation. For instance, properties that return constant values or perform basic calculations can benefit from inlining.
2. Performance-Critical Code: In scenarios where performance is crucial, such as in high-frequency loops, using inline properties can significantly reduce function call overhead and lead to performance improvements.
3. DSLs (Domain-Specific Languages): Inline properties can be used to create more readable and expressive DSLs. The inlined properties can provide syntactic sugar that enhances the DSL’s usability.
4. Custom Accessors: Inline properties are useful when you want to customize the getter logic for a property without incurring function call overhead.

Examples of Kotlin Inline Properties

Let’s explore a few examples to solidify our understanding.

Example 1: Constant Inline Property

inline val pi: Double
    get() = 3.141592653589793

In this example, the pi property always returns the constant value of Pi.

Example 2: Performance Optimization

data class Point(val x: Int, val y: Int) {
    val magnitude: Double
        inline get() = Math.sqrt(x.toDouble() * x + y.toDouble() * y)
}

fun main() {
    val point = Point(3, 4)
    println("Magnitude of the point: ${point.magnitude}")
}

In this example, the inline property magnitude allows you to access the magnitude of the Point instance without invoking a separate function. The getter’s code is expanded and copied directly at the call site, eliminating the function call overhead.

Example 3: DSL Enhancement

class Element(val tagName: String) {
    inline val cssClass: String
        get() = "$tagName-class"
}

fun main() {
    val div = Element("div")
    println(div.cssClass) // Output: div-class
}

Here, the cssClass property enhances the readability of constructing CSS class names within an HTML DSL.

Rules for Kotlin Inline Properties

1. Inline Modifier

To declare an inline property, use the inline modifier before the property definition. This indicates that the property getter’s code will be inserted directly at the call site.

inline val propertyName: PropertyType
    get() = propertyValue

Example:

inline val pi: Double
    get() = 3.141592653589793

2. Read-Only Properties

Inline properties are read-only; they don’t support custom setters(as don’t have backing fields). You can only define the getter logic. It might feel confusing but don’t worry, you will get a clearer idea as we proceed. So, bear with me.

Example:

data class Point(val x: Int, val y: Int)

inline val Point.magnitude: Double
    get() = Math.sqrt(x.toDouble() * x + y.toDouble() * y)

3. Limited Logic in Getters

Keep the logic inside the inline property getter minimal and straightforward. Avoid complex computations or excessive branching.

Example:

inline val half: Int
    get() = 100 / 2

4. No Property Initialization

You can’t directly initialize the inline property’s value within the property declaration.

Example:

// Not allowed
inline val invalid: Int = 42   

// We will get this compilation error: Inline property cannot have backing field

5. Interaction with Inline Functions

When an inline property is accessed within an inline function, the property’s code is also inlined. This can create a hierarchy of inlining that affects performance and code size.

Example:

inline val greeting: String
    get() = "Hello"

inline fun printGreeting() {
    println(greeting) // The code of 'greeting' property will be inlined here
}

By marking both the property and the function as inline, the property’s getter code is directly placed into the function’s call site. This can optimize performance by avoiding the function call overhead. However, it might lead to larger compiled code if the same property’s getter logic is used in multiple locations.

6. Parameterization with Higher-Order Functions

Inline properties can’t take parameters directly. You can use higher-order functions or lambdas for parameterized behavior.

Example:

inline val greeting: (String) -> String
    get() = { name -> "Hello, $name!" }

fun main() {
    val greetFunction = greeting // Assign the lambda to a variable
    val message = greetFunction("softAai") // Call the lambda with a name
    println(message)   // o/p : Hello, softAai!
}

Inline Modifier and Inline Properties

The inline modifier can be used on accessors of properties that don’t have backing fields. You can annotate individual property accessors. That means we can mark entire property or individual accessors (getter and setter) as inline:

Inline Getter

var ageProperty: Int
    inline get() {
        ...
    }
    set(value) {
        ...
    }

Inline Setter

var ageProperty: Int
    get() {
        ...
    }
    inline set(value) {
        ...
    }

Inline Entire Property

You can also annotate an entire property, which marks both of its accessors as inline:

inline val ageProperty: Int
    get() {
       ...
    }
    set(value) {
        ...
    }

Remember, when you use inline accessors in Kotlin, whether for getters or setters, their code behaves like regular inline functions at the call site. This means that the code inside the accessor is inserted directly where the property is accessed or modified, similar to how inline functions work.

Kotlin Inline Properties and Backing Fields

In Kotlin, properties are usually associated with a backing field — a hidden field that stores the actual value of the property. This backing field is automatically generated by the compiler for properties with custom getters or setters. However, inline properties differ in this aspect.

What Does “No Backing Field” Mean?

When you declare an inline property, the property’s getter code is directly inserted at the call site where the property is accessed. This means that there’s no separate backing field holding the value of the property. Instead, the getter logic is inlined into the code that accesses the property, eliminating the need for a distinct memory location to store the property value.

Implications of No Backing Field

1. Memory Efficiency: Since inline properties don’t require a backing field, they can be more memory-efficient compared to regular properties with backing fields. This can be especially beneficial when dealing with large data structures or frequent property accesses.
2. Direct Calculation: The absence of a backing field means that any calculations performed within the inline property’s getter are done directly at the call site. This can lead to improved performance by avoiding unnecessary memory accesses.

Example: Understanding No Backing Field

Consider the following example of a regular property with a backing field and an inline property:

class Rectangle(val width: Int, val height: Int) {
    // Regular property with backing field
    val area: Int
        get() = width * height
    
    // Inline property without backing field
    inline val perimeter: Int
        get() = 2 * (width + height)
}

fun main() {
    val rectangle = Rectangle(5, 10)
    println("Area: ${rectangle.area}")   // o/p : 50
    println("Perimeter: ${rectangle.perimeter}")  // o/p : 30
}

In this example, the area property has a backing field that stores the result of the area calculation. On the other hand, the perimeter inline property doesn’t have a backing field; its getter code is directly inserted wherever it’s accessed.

When to Use Kotlin Inline Properties without Backing Fields

Inline properties without backing fields are suitable for cases where you want to perform direct calculations or return simple values without the need for separate memory storage. They are particularly useful when the logic within the getter is straightforward and lightweight.

However, remember that inline properties are read-only and can’t have custom setters. We cannot set values to inline properties in the same way we do with regular properties. However, we can use custom setters for performing additional operations other than simple value assignment to it. Therefore, they’re most appropriate for scenarios where the value is determined by a simple calculation or constant.

Restriction: No Backing Field with inline Accessors

In Kotlin, when you use the inline modifier on property accessors (getter or setter), it’s important to note that this modifier is only allowed for accessors that don’t have a backing field associated with them. This means that properties with inline accessors cannot have a separate storage location (backing field) to hold their values.

Reason for the Restriction

The restriction on using inline with properties that have backing fields is in place to prevent potential issues with infinite loops and unexpected behavior. The inlining process could lead to situations where the inlined accessor is calling itself, creating a loop. By disallowing inline on properties with backing fields, Kotlin ensures that this kind of situation doesn’t occur.

Hypothetical Example

Consider the following hypothetical scenario, which would result in an infinite loop if the restriction wasn’t in place:

class InfiniteLoopExample {
    private var _value: Int = 0

    inline var value: Int
        get() = value   // This could lead to an infinite loop
        set(v) {
            _value = v
        }
}

In this example, if the inline modifier were allowed on the getter, an infinite loop would occur since the inline getter is calling itself.

To fix the code and prevent the infinite loop, you should reference the backing property _value in the getter and also make it public, as shown below:

class InfiniteLoopExample {
    var _value: Int = 0   // // Change visibility to public

    inline var value: Int
        get() = _value   // Use the backing property here
        set(v) {
            _value = v
        }
}

fun main() {
    val example = InfiniteLoopExample()
    example.value = 42
    println(example.value)
}

Note: By changing the visibility to ‘public,’ you introduce a security risk as it exposes the internal details of your class. This approach is not recommended; even though it violates the ‘no backing field’ rule, I only made these changes for the sake of understanding. Instead, it’s better to follow the rules and guidelines for inline properties.

Real Life Example

inline var votingAge: Int
    get() {
        return 18    // Minimum voting age in India
    }
    set(value) {
        if (value < 18) {
            val waitingValue = 18 - value
            println("Setting: Still waiting $waitingValue years to voting age")
        } else {
            println("Setting: No more waiting years to voting age")
        }
    }

fun main() {
    votingAge = 4
    val votableAge = votingAge
    println("The votable age in India is $votableAge")
}

When you run the code, the following output will be produced:

Setting: Still waiting 14 years to voting age
The votable age in India is 18

In India, the minimum voting age is 18 years old. This means that a person must be at least 18 years old in order to vote in an election. The inline property here stores the minimum voting age in India, and it can be used to check if a person is old enough to vote.

In the code, the value of the votingAge property is set to 4. However, the setter checks if the value is less than 18. Since it is, the setter prints a message saying that the person is still waiting to reach the voting age. The value of the votingAge property is not changed.

This code snippet can be used to implement a real-world application that checks if a person is old enough to vote. For example, it could be used to validate the age of a voter before they are allowed to cast their vote.

Benefits of Kotlin Inline Properties

There are several benefits to using Kotlin inline properties:

1. Performance Optimization: Inline properties eliminate the overhead of function calls, resulting in improved performance by reducing the runtime costs associated with accessing properties.
2. Control over Inlining: Inline properties give you explicit control over which properties should be inlined, allowing you to fine-tune performance optimizations for specific parts of your codebase.
3. Cleaner Syntax: Inline properties can lead to cleaner and more concise code by reducing the need for explicit getter methods.
4. Reduced Object Creation: In some cases, inline properties can help avoid unnecessary object creation, as the getter code is inserted directly into the calling code.

• Smaller code size: Inline properties can reduce the size of your compiled code by eliminating the need to create separate functions for the property accessors.
• Easier debugging: Inline properties can make it easier to debug your code by making it easier to see where the property accessors are being called.

Drawbacks of using Kotlin inline properties

There are a few drawbacks to using Kotlin inline properties:

• Increased complexity: Inline properties can make your code more complex, especially if the property accessors are complex.
• Reduced flexibility: Inline properties can reduce the flexibility of your code, because you cannot override or extend the property accessors.

Conclusion

Kotlin’s inline properties provide a powerful mechanism for optimizing code performance and enhancing code structure. By using inline properties, you gain the benefits of both properties and inline functions, leading to more readable and performant code. Understanding when and how to use inline properties can elevate your Kotlin programming skills and contribute to the efficiency of your projects.

Kotlin is a modern programming language that offers powerful features for building robust and type-safe applications. One such feature is generics, which allows developers to write reusable code that can work with different types. In this blog post, we will delve into the concept of Kotlin generics and explore the intricacies of variance, providing clear explanations and practical examples along the way.

In Kotlin, there are some advanced concepts related to generics that we will explore. These concepts include reified type parameters and declaration-site variance. While they may sound unfamiliar, don’t worry! This blog post will cover them in detail.

Generic type parameters

In Kotlin Generics, you can define types that have type parameters, allowing for more flexible and reusable code. When you create an instance of such a type, you substitute the type parameters with specific types, known as type arguments. This allows you to specify the kind of data that will be stored or processed by the type.

For example, let’s consider the List type. In Kotlin, you can declare a variable of type List<String>, which means it holds a list of strings. Similarly, the Map type has type parameters for the key type (K) and the value type (V). You can instantiate a Map with specific arguments, such as Map<String, Person>, which represents a map with string keys and Person values.

In many cases, the Kotlin compiler can infer the type arguments based on the context. For example:

val authors = listOf("Stan Lee", "J.K Rowling")

Here, since both values passed to the listOf function are strings, the compiler infers that you’re creating a List<String>. However, when creating an empty list, there is nothing to infer the type argument from, so you need to specify it explicitly. You have two options for specifying the type argument:

// here created empty list, so nothing to infer, so specified type argument(i.e String) explicitly.
val readers: MutableList<String> = mutableListOf()
val readers = mutableListOf<String>()  

Both of these declarations are equivalent and create an empty mutable list of strings.

It’s important to note that Kotlin always requires type arguments to be either specified explicitly or inferred by the compiler. In contrast, Java allows the use of raw types, where you can declare a variable of a generic type without specifying the type argument. However, Kotlin does not support raw types, and type arguments must always be defined.

So, in Kotlin, you won’t encounter situations where you can use a generic type without providing the type arguments explicitly or inferring them through type inference.

Generic functions and properties

In Kotlin generics, You can write generic functions and properties to work with any type, providing flexibility and reusability. Generic functions have their own type parameters, which are replaced with specific type arguments when invoking the function. Similarly, generic properties allow you to define properties that are parameterized by a type.

Let’s explore examples of generic functions and properties to understand how they work.

Generic Functions

To illustrate, let’s consider the slice function, which returns a list containing elements at specified indices. Its declaration looks like this:

fun <T> List<T>.slice(indices: IntRange): List<T> {
    // Implementation goes here
}

In this example, <T> is the type parameter, which represents the unknown type that will be specified when calling the function. The List<T> is the receiver type, indicating that this function is an extension function for lists. The return type List<T> ensures that the resulting list has the same type as the input list.

When invoking the slice function, you can either explicitly specify the type argument or rely on type inference:

val letters = ('a'..'z').toList()
println(letters.slice<Char>(0..2)) // Specifies the type argument explicitly, o/p - [a, b, c]
println(letters.slice(10..13)) // The compiler infers that T is Char here, o/p - [k, l, m, n]

The compiler can often infer the type argument based on the context, so you don’t need to explicitly provide it. In both cases, the result type will be List<Char>.

Generic type parameter used in parameter Function Type

When a generic type parameter is used in a parameter function type like (T) -> Boolean, it allows the function to accept a lambda or function that operates on elements of the generic type. The compiler infers the type based on the context and ensures type safety throughout the filtering process. Let’s see it in detail.

Consider the filter function, which filters a list based on a provided predicate. Its declaration looks like this:

fun <T> List<T>.filter(predicate: (T) -> Boolean): List<T> {
    // Implementation goes here
}

In this example, <T> is the type parameter, representing the unknown type that will be specified when calling the function. The List<T> is the receiver type, indicating that this function is an extension function for lists. The predicate parameter has the function type (T) -> Boolean, which means it accepts a function that takes a parameter of type T and returns a Boolean value.

When using the filter function, you can provide a lambda expression as the predicate. The compiler infers the type based on the function’s declaration and the type of the list being filtered. Here’s an example:

val authors = listOf("Stan Lee", "J.K.Rowling")
val readers = mutableListOf<String>(/* ... */)

val filteredReaders = readers.filter { it !in authors }

In this case, the lambda expression { it !in authors } is used as the predicate. The compiler determines that the lambda parameter it has the type T, which is inferred to be String because the filter function is called on List<String> (readers).

By utilizing the generic type parameter T in the function declaration, the filter function can work with any type of list and apply the provided predicate accordingly.

Generic Extension Properties

Similar to generic functions, you can declare generic extension properties using the same syntax. For example, let’s define an extension property penultimate that returns the element before the last one in a list:

val <T> List<T>.penultimate: T      // This generic extension property can be called on a list of any kind
    get() = this[size - 2]

In this case, <T> is the type parameter, and it is part of the receiver type List<T>. The get() function provides the implementation for retrieving the penultimate element.

You can then use the penultimate property on a list:

println(listOf(1, 2, 3, 4).penultimate)   //The type parameter T is inferred to be Int in this invocation
// Output: 3

Note that generic non-extension properties are not allowed in Kotlin. Regular (non-extension) properties cannot have type parameters because they are associated with a specific class or obect and cannot store multiple values of different types.

If you attempt to declare a generic non-extension property, the compiler will report an error similar to the following:

val <T> x: T = TODO()
// ERROR: type parameter of a property must be used in its receiver type

The error message indicates that the type parameter T used in the property declaration should be associated with its receiver type, but since regular properties are specific to a class or object, it doesn’t make sense to have a generic property that can accommodate multiple types.

Declaring generic classes

Just like in Java, in Kotlin also, you can declare generic classes and interfaces by using angle brackets after the class name and specifying the type parameters within the angle brackets. These type parameters can then be used within the body of the class, just like any other types.

For example, let’s consider the declaration of the standard Java interface List in Kotlin:

interface List<T> {
    operator fun get(index: Int): T
    // ...
}

In this example, List is declared as a generic interface with a type parameter T. You can use this type parameter in the interface’s methods and other declarations.

When a class extends a generic class or implements a generic interface, you need to provide a type argument for the generic parameter of the base type. This type argument can be a specific type or another type parameter.

Here are a couple of examples:

class StringList : List<String> {
    override fun get(index: Int): String = ...
}

class ArrayList<T> : List<T> {
    override fun get(index: Int): T = ...
}

In the first example, the StringList class extends List<String>, which means it specifically contains String elements. The get function in StringList will have the signature fun get(index: Int): String instead of fun get(index: Int): T.

In the second example, the ArrayList class defines its own type parameter T and specifies it as the type argument for the superclass List<T>.

Note that T in ArrayList is not the same as in List — it’s a new type parameter, and it doesn’t need to have the same name.

Additionally, a class can even refer to itself as a type argument. Classes implementing the Comparable interface are the classical example of this pattern. Any comparable element must define how to compare it with objects of the same type:

interface Comparable<T> {
    fun compareTo(other: T): Int
}

class String : Comparable<String> {
    override fun compareTo(other: String): Int = /* ... */
}

In this example, the String class implements the generic Comparable interface by specifying String as the type argument for the type parameter T.

Type parameter constraints

Type parameter constraints in Kotlin allow you to limit the types that can be used as arguments for a class or function. This ensures that only specific types or their subtypes can be used.

When you specify a type as an upper bound constraint for a type parameter of a generic type, the corresponding type arguments in specific instantiations of the generic type must be either the specified type or its subtypes(For now, you can think of subtype as a synonym for subclass).

To specify a constraint, you put a colon after the type parameter name, followed by the type that’s the upper bound for the type parameter. In Java, you use the keyword extends to express the same concept: T sum(List list)

Let’s start with an example. Suppose we have a function called sum that calculates the sum of elements in a list. We want this function to work with List<Int> or List<Double>, but not with List<String>. To achieve this, we can define a type parameter constraint that specifies the type parameter of sum must be a number.

fun <T : Number> sum(list: List<T>): T {
    var result = 0.0
    for (element in list) {
        result += element.toDouble()
    }
    return result as T
}

In this example, we specify <T : Number> as the type parameter constraint, indicating that T must be a subclass of Number. Now, when we invoke the function with a list of integers, it works correctly:

println(sum(listOf(1, 2, 3))) // Output: 6

The type argument Int extends Number, so it satisfies the type parameter constraint.

You can also use methods defined in the class used as the bound for the type parameter constraint. Here’s an example:

fun <T : Number> oneHalf(value: T): Double {
    return value.toDouble() / 2.0
}

println(oneHalf(3)) // Output: 1.5

In this case, T is constrained to be a subclass of Number, so we can use methods defined in the Number class, such as toDouble().

Now let’s consider another example where we want to find the maximum of two items. Since it’s only possible to compare items that are comparable to each other, we need to specify that requirement in the function signature using the Comparable interface:

fun <T : Comparable<T>> max(first: T, second: T): T {
    return if (first > second) first else second
}

println(max("kotlin", "java")) // Output: kotlin

In this case, we specify <T : Comparable<T>> as the type parameter constraint. It ensures that T can only be a type that implements the Comparable interface. Hence, we can compare first and second using the > operator.

If you try to call max with incomparable items, such as a string and an integer, it won’t compile:

println(max("kotlin", 42)) // ERROR: Type parameter bound for T is not satisfied

The error occurs because the type argument Any inferred for T is not a subtype of Comparable<Any>, which violates the type parameter constraint.

In some cases, you may need to specify multiple constraints on a type parameter. You can use a slightly different syntax for that. Here’s an example where we ensure that the given CharSequence has a period at the end and can be appended:

fun <T> ensureTrailingPeriod(seq: T)
        where T : CharSequence, T : Appendable {
    if (!seq.endsWith('.')) {
        seq.append('.')
    }
}

val helloWorld = StringBuilder("Hello World")
ensureTrailingPeriod(helloWorld)
println(helloWorld) // Output: Hello World.

In this case, we specify the constraints T : CharSequence and T : Appendable using the where clause. This ensures that the type argument must implement both the CharSequence and Appendable interfaces, allowing us to use operations like endsWith and append on values of that type

Type parameter constraints are also commonly used when you want to declare a non-null type parameter. This helps enforce that the type argument cannot be nullable, ensuring that you always have a non-null value. Let’s see it in more detail.

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 nullableStringProcesor = 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.

Underscore operator ( _ ) for type arguments

The underscore operator _ in Kotlin is a type inference placeholder that allows the Kotlin compiler to automatically infer the type of an argument based on the context and other explicitly specified types.

abstract class SomeClass<T> {
    abstract fun execute() : T
}

class SomeImplementation : SomeClass<String>() {
    override fun execute(): String = "Test"
}

class OtherImplementation : SomeClass<Int>() {
    override fun execute(): Int = 42
}

object Runner {
    inline fun <reified S: SomeClass<T>, T> run() : T {
        return S::class.java.getDeclaredConstructor().newInstance().execute()
    }
}

fun main() {
    // T is inferred as String because SomeImplementation derives from SomeClass<String>
    val s = Runner.run<SomeImplementation, _>()
    assert(s == "Test")

    // T is inferred as Int because OtherImplementation derives from SomeClass<Int>
    val n = Runner.run<OtherImplementation, _>()
    assert(n == 42)
}

Don’t worry! Let’s break down the code step by step:

1. In this code, we have an abstract class called SomeClass with a generic type T. It declares an abstract function execute() that returns an object of type T.
2. We have a class called SomeImplementation which extends SomeClass and specifies the generic type as String. It overrides the execute() function and returns the string value "Test".
3. Similarly, we have another class called OtherImplementation which extends SomeClass and specifies the generic type as Int. It overrides the execute() function and returns the integer value 42.
4. Below that, we have an object called Runner with a function run(). This function is generic and has two type parameters S and T. It uses the reified keyword to access the type information at runtime. Inside the function, it creates an instance of the specified class S using reflection (getDeclaredConstructor().newInstance()) and calls the execute() function on it, returning the result of type T.

In the above code, the underscore operator is used in the main() function when calling the Runner.run() function. Let’s take a closer look:

val s = Runner.run<SomeImplementation, _>()

In this line, the type parameter T is explicitly specified as _ for the Runner.run() function. Here, _ acts as a placeholder for the type to be inferred by the compiler. Since SomeImplementation derives from SomeClass<String>, the compiler infers T as String for this invocation. Therefore, the variable s is inferred to be of type String, and the Runner.run() function returns the result of executing SomeImplementation, which is the string "Test".

val n = Runner.run<OtherImplementation, _>()

Similarly, in this line, the type parameter T is specified as _ for the Runner.run() function. Since OtherImplementation derives from SomeClass<Int>, the compiler infers T as Int for this invocation. Consequently, the variable n is inferred to be of type Int, and the Runner.run() function returns the result of executing OtherImplementation, which is the integer 42.

By using the underscore operator _ as a type argument, the compiler can automatically infer the appropriate type based on the context and the explicitly specified types.

BTW, how do generics work at runtime?

In Kotlin, generics are a compile-time feature rather than a runtime feature. This means that type information is erased at runtime and not available for inspection or manipulation by the program.

When you use generics in Kotlin, the compiler performs type checking and ensures type safety at compile time. It enforces that the correct types are used in generic functions or classes based on the type parameters specified.

At runtime, Kotlin uses type erasure to remove the generic type information. This is done for compatibility with Java, as both languages share a common runtime environment known as the Java Virtual Machine (JVM). The JVM does not natively support reified generics, which would allow for preserving type information at runtime.

Due to type erasure, you cannot directly access the type parameters of a generic class or function at runtime. For example, if you define a List<String> and a List<Int>, they both become List<Any> at runtime.

However, there are cases where Kotlin provides a workaround for working with generics at runtime using reified types. The reified keyword can be used in inline functions to retain type information within the body of the function. This allows you to perform type checks or access the class instance of the type parameter within the function.

Here’s an example of an inline function that utilizes reified types to perform type checks at runtime:

inline fun <reified T> getType(obj: T) {
    if (obj is T) {
        println("Object is of type ${T::class.simpleName}")
    } else {
        println("Object is not of type ${T::class.simpleName}")
    }
}

In this example, the reified T declaration allows you to access the class instance of the type parameter T using T::class. This wouldn’t be possible without the reified keyword.

Please note that although reified types enable limited runtime access to type information, they only work within the scope of inline functions. Outside of inline functions, the type information is still erased at runtime.

Variance: generics and subtyping

The concept of variance describes how types with the same base type and different type arguments relate to each other: for example, List<String> and List<Any>. It’s important to understand variance when working with generic classes or functions because it helps ensure the safety and consistency of your code.

Why variance exists: passing an argument to a function

To illustrate why variance is important, let’s consider passing arguments to functions. Suppose we have a function that takes a List<Any> as an argument. Is it safe to pass a variable of type List<String> to this function?

In the case of a function that prints the contents of the list, such as:

fun printContents(list: List<Any>) {
    println(list.joinToString())
}

You can safely pass a list of strings (List<String>) to this function. Each element in the list is treated as an Any, and since String is a subtype of Any, it is considered safe.

However, let’s consider another function that modifies the list:

fun addAnswer(list: MutableList<Any>) {
    list.add(42)
}

If you attempt to pass a list of strings (MutableList<String>) to this function, like so:

val strings = mutableListOf("abc", "bac")
addAnswer(strings)
println(strings.maxBy { it.length })

You will encounter a ClassCastException at runtime. This occurs because the function addAnswer tries to add an integer (42) to a list of strings. If the compiler allowed this, it would lead to a type inconsistency when accessing the contents of the list as strings. To prevent such issues, the Kotlin compiler correctly forbids passing a MutableList<String> as an argument when a MutableList<Any> is expected.

So, the answer to whether it’s safe to pass a list of strings to a function expecting a list of Any objects depends on whether the function modifies the list. If the function only reads the list, it is safe to pass a List with a more specific element type. However, if the list is mutable and the function adds or replaces elements, it is not safe.

Kotlin provides different interfaces, such as List and MutableList, to control safety based on mutability. If a function accepts a read-only list, you can pass a List with a more specific element type. However, if the list is mutable, you cannot do that.

In the upcoming sections, we’ll explore these concepts in the context of generic classes. We’ll also examine why List and MutableList differ regarding their type arguments. But before that, let’s discuss the concepts of type and subtype.

Difference between Classes, types, and subtypes

In Kotlin, the type of a variable specifies the possible values it can hold. The terms “type” and “class” are sometimes used interchangeably, but they have distinct meanings. In the case of a non-generic class, the class name can be used directly as a type. For example, var x: String declares a variable that can hold instances of the String class. However, the same class name can also be used to declare a nullable type, such as var x: String? which indicates that the variable can hold either a String or null. So each Kotlin class can be used to construct at least two types.

When it comes to generic classes, things get more complex. To form a valid type, you need to substitute a specific type as a type argument for the class’s type parameter. For example, List is a class, not a type itself, but the following substitutions are valid types: List<Int>, List<String?>, List<List<String>>, and so on. Each generic class can generate an infinite number of potential types.

To discuss the relationship between types, it’s important to understand the concept of subtyping. Type B is considered a subtype of type A if you can use a value of type B wherever a value of type A is expected. For example, Int is a subtype of Number, but Int is not a subtype of String. Note that a type is considered a subtype of itself. The term “supertype” is the opposite of subtype: if A is a subtype of B, then B is a supertype of A.

Understanding subtype relationships is crucial because the compiler performs checks whenever you assign a value to a variable or pass an argument to a function. For example:

fun test(i: Int) {
    val n: Number = i
    fun f(s: String) { /*...*/ }
    f(i)
}