In the world of modern programming languages, Kotlin has gained popularity for its flexibility and concise coding style, largely thanks to lambdas or anonymous functions. However, the use of lambdas can introduce overhead due to function calls and memory allocations. To address this concern, Kotlin offers inline functions as a means to optimize code execution. In this blog post, we will delve into inline functions in Kotlin, understanding how they work, their limitations, and the advantages they offer over lambdas. Additionally, we will explore advanced concepts such as noinline, crossinline, and reified types that further enhance the capabilities of inline functions.

Understanding Inline Functions in Kotlin

In Kotlin, inline functions can help remove the overhead associated with lambdas and improve performance. When you use a lambda expression, it is typically compiled into an anonymous class. This means that each time you use a lambda, an additional class is created. Moreover, if the lambda captures variables, a new object is created for each invocation. As a result, using Lambdas can introduce runtime overhead and make the implementation less efficient compared to directly executing the code.

To mitigate this performance impact, Kotlin provides the inline modifier for functions. When you mark a function with inline, the compiler replaces every call to that function with the actual code implementation, instead of generating a function call. This way, the overhead of creating additional classes and objects is avoided.

Let’s see a simple example to illustrate this:

inline fun multiply(a: Int, b: Int): Int {
    return a * b
}

fun main() {
    val result = multiply(2, 3)
    println(result)
}

In this example, the multiply function is marked as inline. When you call multiply(2, 3), the compiler replaces the function call with the actual code of the multiply function:

fun main() {
    val result = 2 * 3  // only for illustrating purposes, later we will see how it actually works 
    println(result)
}

This allows the code to execute the multiplication directly without the overhead of a function call.

Let’s see one more example to illustrate this:

inline fun performOperation(a: Int, b: Int, operation: (Int, Int) -> Int): Int {
    return operation(a, b)
}

fun main() {
    val result = performOperation(5, 3) { x, y -> x + y }
    println(result)
}

In this example, the performOperation function is marked as inline. It takes two integers, a and b, and a lambda expression representing an operation to be performed on a and b. When performOperation is called, instead of generating a function call, the compiler directly replaces the code inside the function with the code from the lambda expression.

So, in the main function, the call to performOperation(5, 3) will be replaced with the actual code 5 + 3. This eliminates the overhead of creating an anonymous class and improves performance.

BTW, How inlining works actually?

When you declare a function as inline in Kotlin, its body is substituted directly into the places where the function is called, instead of being invoked as a separate function. This substitution process is known as inlining.

Let’s take a look at an example to understand it more:

inline fun <T> synchronized(lock: Lock, action: () -> T): T {
    lock.lock()
    try {
        return action()
    } finally {
        lock.unlock()
    }
}

In this example, the synchronized function is declared as inline. It takes a Lock object and a lambda action as parameters. The function locks the Lock object, executes the provided action lambda, and then releases the lock.

When you use the synchronized function, the code generated for every call to it is similar to a synchronized statement in Java.

Here’s an example of usage:

fun foo(l: Lock) {
    println("Before sync")
    synchronized(l) {
        println("Action")
    }
    println("After sync")
}

The equivalent code, which will be compiled to the same bytecode, is:

fun foo(l: Lock) {
    println("Before sync")
    l.lock()
    try {
        println("Action")
    } finally {
        l.unlock()
    }
    println("After sync")
}

In this case, the lambda expression passed to synchronized is substituted directly into the code of the calling function. The bytecode generated from the lambda becomes part of the definition of the calling function and is not wrapped in an anonymous class implementing a function interface.

Not inlined Case (passing lambda as a parameter)

It’s worth noting that if you call an inline function and pass a parameter of a function type from a variable, rather than a lambda directly, the body of the inline function is not inlined.

Here’s an example:

class LockOwner(val lock: Lock) {
    fun runUnderLock(body: () -> Unit) {
        synchronized(lock, body)    // A variable of a function type is passed as an argument, not a lambda.
    }
}

In this case, the lambda’s code is not available at the site where the inline function is called, so it cannot be inlined. The body of the runUnderLock function is not inlined because there’s no lambda at the invocation. Only the body of the synchronized function is inlined; the lambda is called as usual. The runUnderLock function will be compiled to bytecode similar to the following function:

class LockOwner(val lock: Lock) {
    fun __runUnderLock__(body: () -> Unit) {  // This function is similar to the bytecode the real runUnderLock is compiled to
        lock.lock()
        try {
            body()    // The body isn’t inlined, because there’s no lambda at the invocation.
        } finally {
            lock.unlock()
        }
    }
}

Here, the body of the runUnderLock function cannot be inlined because the lambda is passed as a parameter from a variable (body) rather than directly providing a lambda expression.

Suppose when you pass a lambda as a parameter directly, like this:

lockOwner.runUnderLock {
    // code block A
}

The body of the inline function runUnderLock can be inlined, as the compiler knows the exact code to replace at the call site.

However, when you pass a lambda from a variable, like this:

val myLambda = {
    // code block A
}
lockOwner.runUnderLock(myLambda)

The body of the inline function cannot be inlined because the compiler doesn’t have access to the code inside the lambda (myLambda) at the call site. It would require the compiler to know the contents of the lambda in order to inline it.

In such cases, the function call behaves like a regular function call, and the body of the function is not copied to the call site. Instead, the lambda is passed as an argument to the function and executed within the function’s context.

So, suppose even though the runUnderLock function is marked as inline, the body of the function won’t be inlined because the lambda is passed as a parameter from a variable.

What about multiple inlining?

If you have two uses of an inline function in different locations with different lambdas, each call site will be inlined independently. The code of the inline function will be copied to both locations where you use it, with different lambdas substituted into it.

If you have multiple calls to the inline function with different lambdas, like this:

lockOwner.runUnderLock {
    // code block A
}

lockOwner.runUnderLock {
    // code block B
}

Each call site will be inlined independently. The code of the inline function will be copied to both locations where you use it, with different lambdas substituted into it. This allows the compiler to inline the code at each call site separately.

Restrictions on inline functions

When a function is declared as inline in Kotlin, the body of the lambda expression passed as an argument is substituted directly into the resulting code. However, this substitution imposes certain restrictions on how the corresponding parameter can be used in the function body.

If the parameter is called directly within the function body, the code can be easily inlined. But if the parameter is stored for later use, the code of the lambda expression cannot be inlined because there must be an object that contains this code.

In general, the parameter can be inlined if it’s called directly or passed as an argument to another inline function. If it’s used in a way that prevents inlining, such as storing it for later use, the compiler will prohibit the inlining and show an error message stating “Illegal usage of inline-parameter.”

Let’s consider an example with the Sequence.map function:

fun <T, R> Sequence<T>.map(transform: (T) -> R): Sequence<R> {
    return TransformingSequence(this, transform)
}

The map function doesn’t call the transform function directly. Instead, it passes the transform function as a constructor parameter to a class (TransformingSequence) that stores it in a property. To support this, the lambda passed as the transform argument needs to be compiled into the standard non-inline representation, which is an anonymous class implementing a function interface.

“noinline” Modifier

In situations where a function expects multiple lambda arguments, you can choose to inline only some of them. This can be useful when one of the lambdas contains a lot of code or is used in a way that doesn’t allow inlining. To mark parameters that accept non-inlineable lambdas, you can use the noinline modifier:

inline fun foo(inlined: () -> Unit, noinline notInlined: () -> Unit) {
    // ...
}

By using noinline, you indicate that the notInlined parameter should not be inlined.

Note that the compiler almost fully supports inlining functions across modules, or functions defined in third-party libraries(we will discuss more at the end of this blog). You can also call most inline functions from Java; such calls will not be inlined but will be compiled as regular function calls.

Inlining collection operations

In Kotlin, the standard library provides a set of collection functions that accept lambda expressions as arguments. These functions, such as filter, map, and others, are declared as inline, which means that the bytecode of both the function and the lambda will be inlined at the call site.

Let’s compare the performance of filtering a list of people using the filter function with a lambda expression versus manually filtering the list using a loop:

///////////// manually //////////////////


data class Person(val name: String, val age: Int)

val result = mutableListOf<Person>()

for (person in people) {
    if (person.age < 30) result.add(person)
}

println(result) // [Person(name=Alice, age=29)]

////////////// with lambda /////////////////


val people = listOf(Person("Alice", 29), Person("Bob", 31))

println(people.filter { it.age < 30 }) // [Person(name=Alice, age=29)]

This code uses the filter function to filter the list based on the condition specified in the lambda expression { it.age < 30 }. The resulting code will be roughly the same as manually filtering the list using a loop.

The reason for this is that the filter function is declared as inline, and its bytecode, along with the bytecode of the lambda, will be substituted directly into the calling code. This eliminates the overhead of function calls and lambda object creation, resulting in efficient code execution.

Now, let’s consider a chain of operations where both filter and map are applied:

println(people.filter { it.age > 30 }.map(Person::name))

In this example, both filter and map functions are declared as inline. However, there is an intermediate collection created to store the result of filtering before applying the mapping operation. The code generated from the filter function adds elements to this intermediate collection, and the code generated from map reads from it.

If the number of elements to process is large and the overhead of the intermediate collection becomes a concern, you can use a Sequence instead by adding an asSequence call to the chain. However, it’s important to note that lambdas used to process a Sequence are not inlined. Each intermediate sequence is represented as an object storing a lambda in its field, and the terminal operation involves a chain of calls through each intermediate sequence. Therefore, adding asSequence calls to every chain of collection operations may not provide performance benefits for smaller collections and is more suitable for larger collections.

So, you can safely use idiomatic collection operations in Kotlin’s standard library functions, as they are declared as inline and their bytecode, along with the lambda expressions, will be inlined at the call site. If performance becomes a concern for larger collections, you can consider using Sequence and asSequence calls, but it’s not necessary for smaller collections, as regular collection operations perform well.

Deciding when to declare functions as inline

When deciding whether to declare a function as inline, it’s important to consider the specific circumstances and the type of function being used.

For regular function calls, it’s generally not necessary to use the inline keyword. The JVM already has powerful inlining support and automatically analyzes the code to inline calls when it provides the most benefit. The JVM performs this optimization while translating bytecode to machine code. Additionally, calling functions directly without inlining can provide clearer stack traces.

On the other hand, declaring functions as inline is beneficial when working with functions that take lambdas as arguments. In these cases, the overhead of inlining is more significant. By using the inline keyword, you can save on the function call overhead as well as the creation of additional classes and objects for lambda instances. The JVM currently may not always perform inlining effectively with calls and lambdas, so using the inline keyword can ensure efficient execution.

Furthermore, inlining allows you to use features that are not possible with regular lambdas, such as non-local returns(we will look later here). This can provide additional flexibility and functionality in your code.

However, it’s essential to consider the code size when deciding whether to use the inline modifier. If the function you want to inline is large, copying its bytecode into every call site can result in a significant increase in bytecode size. In such cases, it’s recommended to extract the code that is not related to the lambda arguments into a separate non-inline function. This approach helps manage code size and optimize performance.

It’s worth noting that the inline functions in the Kotlin standard library are typically small, as the developers have taken care to extract non-lambda-related code into separate functions.

So, you should carefully consider whether to use the inline keyword based on the specific circumstances and the type of function being used. Regular function calls can rely on the JVM’s inlining support, while functions with lambda arguments can benefit from the inline modifier to reduce overhead and enable additional features. Pay attention to code size and consider extracting unrelated code into separate non-inline functions if necessary.

Using inlined lambdas for resource management

Lambdas can be useful for simplifying code duplication when it comes to resource management. Resource management involves acquiring a resource before performing an operation and releasing it afterward. Resources can include files, locks, database transactions, and more.

Traditionally, the try/finally statement is used to implement this pattern. The resource is acquired before the try block and released in the finally block. However, in Kotlin, you can encapsulate the logic of the try/finally statement in a function and pass the code that uses the resource as a lambda to that function.

For example, the Kotlin standard library provides the withLock function, which offers a more idiomatic API for working with locks:

val l: Lock = ...
l.withLock {
    // Access the resource protected by this lock
}

The withLock function is an extension function defined in the Kotlin library. It takes a lambda as an argument and performs the necessary lock operations:

fun <T> Lock.withLock(action: () -> T): T {
    lock()
    try {
        return action()
    } finally {
        unlock()
    }
}

Files are another type of resource commonly used with this pattern. In Java, the try-with-resources statement was introduced to simplify working with resources. In Kotlin, a similar effect can be achieved using the use function, which is an extension function in the Kotlin standard library.

Here’s an example of rewriting a Java method that reads the first line from a file using the use function in Kotlin:

fun readFirstLineFromFile(path: String): String {
    BufferedReader(FileReader(path)).use { br ->
        return br.readLine()
    }
}

The use function is called on a closable resource and receives a lambda as an argument. It ensures that the resource is closed properly, regardless of whether the lambda completes normally or throws an exception. The use function is inlined, meaning it doesn’t introduce any performance overhead.

Note that in the body of the lambda, a non-local return is used to return a value from the readFirstLineFromFile function.

Control flow in higher-order functions

When using higher-order functions like filter or forEach in Kotlin, the behavior of return statements changes. If you use a return statement inside a loop, it’s straightforward to understand that it will exit the loop. However, when you convert the loop into a higher-order function, such as filter, the return statement works differently.

Return statements in lambdas: return from an enclosing function

If you use a return statement inside a lambda passed to a higher-order function like forEach, it will not only exit the lambda but also return from the function that called the lambda. This type of return statement is called a non-local return because it affects a larger block of code than just the lambda itself.

To illustrate this, let’s consider an example. Suppose we have a list of Person objects and we want to find if there is a person named “Alice”:

data class Person(val name: String, val age: Int)
val people = listOf(Person("Alice", 29), Person("Bob", 31))

fun lookForAlice(people: List<Person>) {
    people.forEach {
        if (it.name == "Alice") {
            println("Found!")
            return
        }
    }
    println("Alice is not found")
}

In this example, if the lambda inside forEach encounters a person with the name “Alice,” it will print “Found!” and immediately return from the lookForAlice function. However, if no person named “Alice” is found, it will execute the last line and print “Alice is not found.”

Non-local returns

If you use the return keyword in a lambda, it returns from the function in which you called the lambda, not just from the lambda itself. Such a return statement is called a non-local return because it returns from a larger block than the block containing the return statement. To understand the logic behind the rule, think about using a return keyword in a for loop or a synchronized block in a Java method. It’s obvious that it returns from the function and not from the loop or block

Note that the return from the outer function is possible only if the function that takes the lambda as an argument is inlined. In the example above, the forEach function is inlined, and the body of the forEach function is inlined together with the body of the lambda, so it’s easy to compile the return expression so that it returns from the enclosing function.

Using the return expression in lambdas passed to non-inline functions isn’t allowed. A non-inline function can save the lambda passed to it in a variable and execute it later, when the function has already returned, so it’s too late for the lambda to affect when the surrounding function returns.

Returning from lambdas: return with a label

You can indeed use a local return within a lambda expression in Kotlin. This type of return is similar to a break statement in a for loop. It allows you to terminate the execution of the lambda and continue executing the code from where the lambda was invoked. To differentiate a local return from a non-local return, you use labels.

To use a label with a lambda expression, you place the label name followed by the @ character before the opening curly brace of the lambda. Then, to perform a local return, you use the return@label syntax, where label represents the name of the label.

Here’s an example to demonstrate the use of labels and local returns:

fun lookForAlice(people: List<Person>) {
    people.forEach label@{
        if (it.name == "Alice") return@label
    }
    println("Alice might be somewhere")
}

In this code, the lambda expression inside the forEach function is labeled with label@. When the condition it.name == "Alice" is true, the return@label statement is executed, causing the lambda to exit. The program then proceeds with the line println("Alice might be somewhere").

It’s worth noting that you can also use the function name as the label for the lambda expression. Here’s an alternative version of the same code using the function name as the label:

fun lookForAlice(people: List<Person>) {
    people.forEach {
        if (it.name == "Alice") return@forEach
    }
    println("Alice might be somewhere")
}

In this case, return@forEach is used to explicitly specify the return label as the function name itself.

Note that if you specify the label of the lambda expression explicitly, labeling using the function name doesn’t work. A lambda expression can’t have more than one label.

Labeled “this” expression

The same rules and concepts of labels also apply to lambdas with receivers. In Kotlin, lambdas with receivers are lambdas that have an implicit context object accessible via the this reference within the lambda. When you specify a label for a lambda with a receiver, you can use the corresponding labeled this expression to access its implicit receiver.

Here’s an example that demonstrates this concept:

println(StringBuilder().apply sb@{          // This lambda’s implicit receiver is accessed by this@sb.
    listOf(1, 2, 3).apply {             // “this” refers to the closest implicit receiver in the scope
        this@sb.append(this.toString())     // All implicit receivers can be accessed,the outer ones via explicit labels.
    }
})

Here’s a breakdown of the code:

1. StringBuilder().apply sb@{...}: This line creates a new StringBuilder instance using the constructor StringBuilder(). The apply function is then called on the StringBuilder instance. The sb@ label is used to explicitly label the lambda expression.
2. listOf(1, 2, 3).apply {...}: Inside the lambda expression, the apply function is called on a List created using listOf(1, 2, 3). This apply function is invoked on the List itself and not on the StringBuilder instance.
3. [email protected](this.toString()): The code within the lambda expression appends the string representation of the List (obtained through this.toString()) to the StringBuilder instance. The this@sb syntax refers to the implicit receiver of the outer lambda expression (StringBuilder instance).

It’s important to note that when using labels for lambdas with receivers, you can explicitly specify the label for the lambda expression, or you can use the function name as a label.

Anonymous functions: local returns by default

The non-local return syntax is fairly verbose and becomes cumbersome if a lambda contains multiple return expressions. Multiple return expressions mean lambda expressions that have more than one return statement within their body. This means that the lambda code can have multiple points where it can exit and return a value or terminate the execution.

Here’s an example of a lambda with multiple return statements:

val numbers = listOf(1, 2, 3, 4, 5)

val result = numbers.map {
    if (it % 2 == 0) {
        return@map "Even"  // Return statement 1
    } else {
        return@map "Odd"   // Return statement 2
    }
}

To address this, you can use anonymous functions as an alternative syntax to pass around blocks of code. Anonymous functions provide a concise way to handle multiple returns within a block of code without the need for labels.

Here’s an example that demonstrates the use of anonymous functions to handle multiple returns:

val numbers = listOf(1, 2, 3, 4, 5)

val result = numbers.map(fun(number): String {
    if (number % 2 == 0) {
        return "Even"  // Return statement 1
    } else {
        return "Odd"   // Return statement 2
    }
})

Here’s an explanation of the code:

1. val numbers = listOf(1, 2, 3, 4, 5): This line creates a list of integers containing the numbers 1, 2, 3, 4, and 5.
2. val result = numbers.map(fun(number): String {...}): The map function is called on the numbers list. It takes an anonymous function as an argument. The anonymous function accepts a single parameter number and returns a String. The map function applies this anonymous function to each element of the numbers list and creates a new list with the transformed values.
3. if (number % 2 == 0) { return "Even" } else { return "Odd" }: Within the anonymous function, this code block checks if the number is even or odd. If it’s even (when number % 2 == 0), the string “Even” is returned. Otherwise, if it’s odd, the string “Odd” is returned.
4. The returned string from each iteration of the anonymous function is collected by the map function, resulting in a new list result that contains the strings “Odd”, “Even”, “Odd”, “Even”, and “Odd” in this case.

Note that using anonymous functions can simplify the handling of multiple returns within a lambda expression.

Let’s see, how can this be possible?

An anonymous function is another way to write a block of code passed to a function. It is similar to a regular function, but its name and parameter types are omitted. Here’s an example:

fun lookForAlice(people: List<Person>) {
    people.forEach(fun(person) {
        if (person.name == "Alice") return
        println("${person.name} is not Alice")
    })
}

In this example, the anonymous function is used inside the forEach function. It follows the same rules as regular functions for specifying the return type. Anonymous functions with a block body require the return type to be explicitly specified. However, if an expression body is used, the return type can be omitted.

Inside an anonymous function, a return expression without a label will return from the anonymous function itself, not from the enclosing function. The rule is that return returns from the closest function declared using the fun keyword. In contrast, lambda expressions do not use the fun keyword, so a return in a lambda expression returns from the outer function. The difference is illustrated here:

Here’s a comparison between an anonymous function return and a lambda expression return:

fun lookForAlice(people: List<Person>) {
    people.forEach(fun(person) {
        if (person.name == "Alice") return  // Returns from the anonymous function
    })
}

fun lookForAlice(people: List<Person>) {
    people.forEach {
        if (it.name == "Alice") return  // Returns from the enclosing function
    }
}

Note that despite the similar appearance to regular function declarations, anonymous functions are another syntactic form of lambda expressions. The implementation details and inlining behavior for lambda expressions also apply to anonymous functions.

“crossinline” Modifier

the crossinline modifier in Kotlin is used to restrict non-local returns from lambdas. It helps ensure that lambdas passed to certain functions cannot use the return keyword to perform a non-local return.

But why do we need this “crossinline”?

Well, sometimes we pass lambdas to functions that are not inlined, such as higher-order functions, local objects, or nested functions. In these cases, the lambda can be executed in a different context from where it was defined. If the lambda could perform a non-local return, it might cause unexpected behavior or make the code harder to understand.

In Kotlin, when we pass a lambda to a higher-order function or a non-inlined function, the lambda can be executed in a different context from where it was defined. This means that the lambda may be called outside its original scope. By default, a lambda can have a non-local return, which means it can exit not only from itself but also from the surrounding function. However, in some cases, allowing non-local returns can lead to unexpected behavior or make the code harder to understand.

Here are a few simplified real-time use cases where crossinline can be useful:

1. Asynchronous Callbacks: Imagine a scenario where you have an asynchronous operation that takes a callback function. The callback function is executed when the operation completes. If the callback could perform a non-local return, it might prematurely exit the surrounding function, causing unexpected behavior. By marking the callback as crossinline, you ensure that it executes within the proper context and doesn’t exit the surrounding function prematurely.
2. Resource Management: Consider a function that manages the acquisition and release of resources, such as opening and closing a file. The function takes a lambda as a parameter to perform some operations on the resource. If the lambda could perform a non-local return, it might skip the resource release step, leading to resource leaks. By marking the lambda as crossinline, you ensure that the resource release step is always executed before the function returns.
3. Error Handling: In error handling scenarios, you might have a function that takes a lambda to handle the error case. If the lambda could perform a non-local return, it might bypass the necessary error handling steps defined within the surrounding function. By using crossinline, you ensure that the error-handling logic remains intact and is always executed within the proper context.

In these use cases, using crossinline helps maintain the expected flow and behavior of the code, preventing unexpected returns or skipping important steps within the surrounding function.

The purpose of crossinline is to enforce that such lambdas cannot perform non-local returns. By marking a lambda parameter as crossinline, we explicitly state that it should not use the return keyword to return from outside the lambda’s scope.

Let’s see an example to illustrate this concept:

inline fun higherOrderFunction(crossinline aLambda: () -> Unit) {
    normalFunction {
        aLambda() // Using aLambda inside normalFunction
    }
}

fun normalFunction(aLambda: () -> Unit) {
    return  // Normal return from normalFunction
}

fun main() {
    higherOrderFunction {
        return  // Error: Cannot perform non-local return from a crossinline lambda
    }
}

In this example, we have a higher-order function called higherOrderFunction that takes a lambda parameter aLambda marked as crossinline. Inside higherOrderFunction, we invoke normalFunction and pass aLambda to it. Since aLambda is marked as crossinline, it cannot perform a non-local return.

Now, in the main function, we call higherOrderFunction and provide a lambda that tries to perform a non-local return using return. However, since the lambda is marked as crossinline, this will result in a compilation error.

The use of crossinline in this example ensures that the lambda passed to higherOrderFunction cannot perform non-local returns. This restriction makes the code easier to reason about and prevents potential issues that might arise from non-local returns in certain contexts.

“reified” Type

In Kotlin, the reified modifier is used in combination with the inline keyword to enable type information to be available at runtime for certain generic functions. It allows us to access and manipulate the type parameter of a generic function inside the function body.

By default, type parameters in Kotlin are erased at runtime due to type erasure.

Type erasure refers to the process by which type information is removed or erased at runtime in languages that employ generics. It is a mechanism used by the Java Virtual Machine (JVM) and other platforms to ensure compatibility with code compiled without generics.

In Kotlin, type parameters are erased at runtime due to type erasure, which means that the actual type arguments used when invoking a generic function or creating a generic class are not retained at runtime. Instead, the compiler replaces type parameters with their upper bounds or with the Any type if no upper bound is specified.

For example, consider the following generic function in Kotlin:

fun <T> printType(item: T) {
    println("Type of item: ${item::class.simpleName}")
}

In this case, when the function is invoked with different type arguments, such as Int or String, the compiled bytecode does not retain information about the specific type argument. The type parameter T is erased, and the compiled code behaves as if it were using the Any type.

The consequence of type erasure is that, at runtime, generic code cannot differentiate between different type arguments. It means that within a generic function, you can’t directly access the specific type information of the type parameter T. For example, you can’t invoke functions or access properties specific to T without additional mechanisms.

However, with the reified modifier, we can retain type information within an inline function. This enables us to perform operations that require type-specific information, such as checking the type, accessing properties, or invoking functions specific to that type.

Here’s an example to illustrate the usage of reified:

inline fun <reified T> printType(item: T) {
    println("Type of item: ${T::class.simpleName}")
}

fun main() {
    val number = 42
    val text = "softAai"

    printType(number) // Output: Type of item: Int
    printType(text)   // Output: Type of item: String
}

In this example, we have an inline function called printType that takes a parameter named item of type T. The T type parameter is marked with the reified modifier. Inside the function, we use T::class to access the runtime class of T and retrieve its simple name.

In the main function, we call printType twice with different types: Int and String. When the function is inlined, the reified modifier allows us to access the type information of T at runtime. As a result, the type name of the item parameter is printed correctly.

The reified modifier simplifies certain operations that require runtime type information and eliminates the need for workarounds or reflection-based approaches. It improves type safety and enables more expressive and concise code.

It’s important to note that the reified modifier can only be used with inline functions, and it’s applicable only to type parameters of the function itself, not the class. Additionally, reified can be used in combination with other language features, such as is checks, when expressions, and function calls specific to the type T.

Overall, the reified modifier in Kotlin is a powerful tool that allows us to work with type information at runtime within inline functions.

Inline properties

Inline properties in Kotlin provide a way to mark property accessors as inline, allowing them to be inlined as regular functions at the call site. This can lead to improved performance and reduced overhead.

The inline modifier can be applied to the getter and setter accessors of properties that don’t have backing fields. You have the flexibility to annotate individual accessors or the entire property.

Here’s an example to illustrate the usage of inline properties:

inline val foo: Foo
    get() = Foo()

inline var bar: Bar
    get() = ...
    set(v) { ... }

In this example, we have an inline property foo with an inline getter. The getter returns an instance of Foo inline, meaning that the code inside the getter will be copied to the call site during compilation.

Similarly, we have an inline property bar with both an inline getter and setter. The getter and setter accessors can contain custom logic, and marking them as inline allows that logic to be inlined at the call site.

At the call site, accessing an inline property is no different from invoking a regular inline function. The property accessors are expanded and copied into the calling code, eliminating the overhead of function calls and providing potential performance benefits.

Let’s dive into a detailed example to explain how marking the setter or getter as inline can eliminate function call overhead.

Consider the following code:

data class Person(val age: Int) {
    val currentAge: Int
        inline get() = age
}

fun main() {
    val person = Person(25)
    println("Current age of the person: ${person.currentAge}")
}

When you access the currentAge property using person.currentAge, the getter for the property is invoked. However, since the getter is marked as inline, its code is expanded and copied directly into the calling code (in this case, the println statement). This behavior is similar to invoking a regular inline function.

In this specific example, the getter’s code is quite simple: it returns the value of the age property. This code is directly inserted where the property is accessed, eliminating the overhead of a separate function call. This inlining results in potential performance benefits by avoiding the function call overhead and making the code more efficient.

The benefit of inlining the getter and setter is that the property accessors’ code is copied directly into the calling code during compilation. This eliminates the need for function calls and reduces the overhead associated with them. The result is improved performance, as the property access becomes as efficient as accessing a regular variable.

By using inline properties, we can achieve better performance when working with simple properties that don’t require complex logic in their accessors. However, it’s worth noting that inlining larger or more complex accessors can lead to increased code size, which might impact maintainability and readability.

So, marking the getter or setter as inline in Kotlin allows the code inside the accessors to be copied directly at the call site, eliminating the function call overhead. This results in improved performance when accessing or modifying inline properties.

Restrictions for public API inline functions

In Kotlin, when you have an inline function that is public or protected, it is considered part of a module’s public API. This means that other modules can call that function, and the function itself can be inlined at the call sites in those modules.

However, there are certain risks of binary incompatibility that can arise when changes are made to the module that declares the inline function, especially if the calling module is not re-compiled after the change.

To mitigate these risks, there are restrictions placed on public API inline functions. These functions are not allowed to use non-public-API declarations, which include private and internal declarations and their parts, within their function bodies.

Using Private Declarations

private fun privateFunction() {
    // Implementation of private function
}

inline fun publicAPIInlineFunction() {
    privateFunction() // Error: Private declaration cannot be used in a public API inline function
    // Rest of the code
}

In this scenario, we have a private function privateFunction(). When attempting to use this private function within the public API inline function publicAPIInlineFunction(), a compilation error will occur. The restriction prevents the usage of private declarations within public API inline functions.

Using Internal Declarations

internal fun internalFunction() {
    // Implementation of internal function
}

inline fun publicAPIInlineFunction() {
    internalFunction() // Error: Internal declaration cannot be used in a public API inline function
    // Rest of the code
}

In this scenario, we have an internal function internalFunction(). When trying to use this internal function within the public API inline function publicAPIInlineFunction(), a compilation error will arise. The restriction prohibits the usage of internal declarations within public API inline functions.

To eliminate this restriction and allow the use of internal declarations in public API inline functions, you can annotate the internal declaration with @PublishedApi. This annotation signifies that the internal declaration can be used in public API inline functions. When an internal inline function is marked with @PublishedApi, its body is checked as if it were a public function.

Using Internal Declarations with @PublishedApi

@PublishedApi
internal fun internalFunction() {
    // Implementation of internal function
}

inline fun publicAPIInlineFunction() {
    internalFunction() // Allowed because internalFunction is annotated with @PublishedApi
    // Rest of the code
}

In this scenario, we have an internal function internalFunction() that is annotated with @PublishedApi. This annotation indicates that the internal function can be used in public API inline functions. Therefore, using internalFunction() within the public API inline function publicAPIInlineFunction() is allowed.

By applying @PublishedApi to the internal declaration, we explicitly allow its usage in public API inline functions, ensuring that the function remains compatible and can be safely used in other modules.

So, the restrictions for public API inline functions in Kotlin prevent them from using non-public-API declarations. However, by annotating internal declarations with @PublishedApi, we can exempt them from this restriction and use them within public API inline functions, thereby maintaining compatibility and enabling safe usage across modules.

Conclusion

Inline functions in Kotlin offer an effective means of optimizing code efficiency by eliminating the overhead of lambdas and function calls. By replacing function calls with the actual function body, inline functions enhance performance and reduce memory usage. Additionally, advanced concepts like noinline, crossinline, and reified types provide further flexibility and control over inline function behavior. By understanding and leveraging these concepts effectively, developers can optimize their code and enhance application performance in Kotlin projects.