Amol Pawar

Generics in Kotlin provide a powerful way to write reusable and type-safe code. However, on the Java Virtual Machine (JVM), generics are subject to type erasure, meaning that the specific type arguments used for instances of a generic class are not preserved at runtime. This limitation has implications for runtime type checks and casts. But fear not! Kotlin provides a solution: reified type parameters. In this blog post, we’ll delve into the world of reified type parameters and explore how they enable us to access and manipulate type information at runtime.

Understanding Type Erasure in Kotlin Generics

Generics in Kotlin are implemented using type erasure on the JVM. This means that the specific type arguments used for instances of a generic class are not preserved at runtime. In this section, we’ll explore the practical consequences of type erasure in Kotlin and learn how you can overcome its limitations by declaring a function as inline.

By declaring a function as inline, you can prevent the erasure of its type arguments. In Kotlin, this is achieved by using reified type parameters. Reified type parameters allow you to access and manipulate the actual type information of the generic arguments at runtime.

In simpler terms, when you mark a function as inline with a reified type parameter, you can retrieve and work with the specific types used as arguments when calling that function.

Now, let’s look at some examples to better understand the concept of reified type parameters and their usefulness.

Generics at runtime: type checks and casts

Generics in Kotlin, similar to Java, are erased at runtime. This means that the type arguments used to create an instance of a generic class are not preserved at runtime. For example, if you create a List<String> and put strings into it, at runtime, you will only see it as a List. You won’t be able to identify the specific type of elements the list was intended to contain. However, the compiler ensures that only elements of the correct type are stored in the list based on the type arguments provided during compilation.

Let’s consider the following code:

val list1: List<String> = listOf("a", "b")
val list2: List<Int> = listOf(1, 2, 3)

Even though the compiler recognizes list1 and list2 as distinct types, at execution time, they appear the same. However, you can generally rely on List<String> to contain only strings and List<Int> to contain only integers because the compiler knows the type arguments and enforces type safety. It is possible to deceive the compiler using type casts or Java raw types, but it requires a deliberate effort.

When it comes to checking the type information at runtime, the erased type information poses some limitations. You cannot directly check if a value is an instance of a specific erased type with type arguments. For example, the following code won’t compile:

if (value is List<String>) { ... } // Error: Cannot check for instance of erased type

Even though you can determine at runtime that value is a List, you cannot determine whether it’s a list of strings, persons, or some other type. That information is erased.

Note that erasing generic type information has its benefits: the overall amount of memory used by your application is smaller; because less type information needs to be saved in memory.

As we stated earlier, Kotlin doesn’t let you use a generic type without specifying type arguments. Thus you may wonder how to check that the value is a list, rather than a set or another object

To check if a value is a List without specifying its type argument, you can use the star projection syntax:

if (value is List<*>) { ... }

By using List<*>, you’re essentially treating it as a type with unknown type arguments, similar to Java’s List<?>. In this case, you can determine that the value is a List, but you won’t have any information about its element type.

Note that you can still use normal generic types in as and as? casts. However, these casts won’t fail if the class has the correct base type but a wrong type argument because the type argument is not known at runtime. The compiler will emit an “unchecked cast” warning for such casts. It’s important to understand that it’s only a warning, and you can still use the value as if it had the necessary type.

Here’s an example of using as? cast with a warning:

fun printSum(c: Collection<*>) {
    val intList =
        c as? List<Int> // Warning here. Unchecked cast: List<*> to List<Int>
         ?: throw IllegalArgumentException("List is expected")
    println(intList.sum())
}

This code defines a function called printSum that takes a collection (c) as a parameter. Within the function, a cast is performed using the as? operator, attempting to cast c as a List<Int>. If the cast succeeds, the resulting value is assigned to the variable intList. However, if the cast fails (i.e., c is not a List<Int>), the as? operator returns null, and the code throws an IllegalArgumentException with the message “List is expected”. Finally, the sum of the integers in intList is printed.

Let’s see how this function behaves when called with different inputs:

printSum(listOf(1, 2, 3))  // o/p - 6

When called with a list of integers, the function works as expected. The sum of the integers is calculated and printed.

Now let’s change the input to a set:

printSum(setOf(1, 2, 3))   // o/p - IllegalArgumentException: List is expected

When called with a set of integers, the function throws an IllegalArgumentException because the input is not a List. The as? cast fails, resulting in a null value, and the IllegalArgumentException is thrown.

Now we pass String as input:

printSum(listOf("a", "b", "c"))  // o/p - ClassCastException: String cannot be cast to Number

When called with a list of strings, the function successfully casts the list to a List<Int>, despite the wrong type argument. However, during the execution of intList.sum(), a ClassCastException occurs. This happens because the function tries to treat the strings as numbers, resulting in a runtime error.

The code examples above demonstrate that type casts (as and as?) in Kotlin may lead to runtime exceptions if the casted type and the actual type are incompatible. The compiler emits an “unchecked cast” warning to notify you about this potential risk. It’s important to understand the meaning of these warnings and be cautious when using type casts.

The code snippet below shows an alternative approach using an is check:

fun printSum(c: Collection<*>) {
    val intList =
        c as? List<Int> // Warning here. Unchecked cast: List<*> to List<Int>
         ?: throw IllegalArgumentException("List is expected")
    println(intList.sum())
}

In this example, the printSum function takes a Collection<Int> as a parameter. Using the is operator, it checks if c is a List<Int>. If the check succeeds, the sum of the integers in the list is printed. This approach is possible because the compiler knows at compile time that c is a collection of integers.

So, Kotlin’s compiler helps you identify potentially dangerous type checks (forbidding is checks) and emits warnings for type casts (as and as?) that may cause issues at runtime. Understanding these warnings and knowing which operations are safe is essential when working with type casts in Kotlin.

Power of Reified Type Parameters in Inline Functions

In Kotlin, generics are typically erased at runtime, which means that you can’t determine the type arguments used when an instance of a generic class is created or when a generic function is called. However, there is an exception to this limitation when it comes to inline functions. By marking a function as inline, you can make its type parameters reified, which allows you to refer to the actual type arguments at runtime.

Let’s take a look at an example to illustrate this. Suppose we have a generic function called isA that checks if a given value is an instance of a specific type T:

fun <T> isA(value: Any) = value is T

If we try to call this function with a specific type argument, like isA<String>("abc"), we would encounter an error because the type argument T is erased at runtime.

However, if we modify the function to be inline and mark the type parameter as reified, like this:

inline fun <reified T> isA(value: Any) = value is T

Now we can call isA<String>("abc") and isA<String>(123) without any errors. The reified type parameter allows us to check whether the value is an instance of T at runtime. In the first example, the output will be true because "abc" is indeed a String, while in the second example, the output will be false because 123 is not a String.

Another practical use of reified type parameters is demonstrated by the filterIsInstance function from the Kotlin standard library. This function takes a collection and selects instances of a specified class, returning only those instances. For example:

val items = listOf("one", 2, "three")
println(items.filterIsInstance<String>())

In this case, we specify <String> as the type argument for filterIsInstance, indicating that we are interested in selecting only strings from the items list. The function’s return type is automatically inferred as List<String>, and the output will be [one, three].

Here’s a simplified version of the filterIsInstance function’s declaration from the Kotlin standard library:

inline fun <reified T> Iterable<*>.filterIsInstance(): List<T> {
    val destination = mutableListOf<T>()
    for (element in this) {
        if (element is T) {
            destination.add(element)
        }
    }
    return destination
}

Before coming to this code explanation, have you ever thought, Why reification works for inline functions only? How does this work? Why are you allowed to write element is T in an inline function but not in a regular class or function? Let’s see the answers to all these questions:

Reification works for inline functions because the compiler inserts the bytecode implementing the inline function directly at every place where it is called. This means that the compiler knows the exact type used as the type argument in each specific call to the inline function.

When you call an inline function with a reified type parameter, the compiler can generate a bytecode that references the specific class used as the type argument for that particular call. For example, in the case of the filterIsInstance<String>() call, the generated code would be equivalent to:

for (element in this) {
    if (element is String) {
        destination.add(element)
    }
}

The generated bytecode references the specific String class, not a type parameter, so it is not affected by the type-argument erasure that occurs at runtime. This allows the reified type parameter to be used for type checks and other operations at runtime.

It’s important to note that inline functions with reified type parameters cannot be called from Java code. Regular inline functions are accessible to Java as regular functions, meaning they can be called but are not inlined. However, functions with reified type parameters require additional processing to substitute the type argument values into the bytecode, and therefore they must always be inlined. This makes it impossible to call them in a regular way, as Java code does not support this mechanism.

Also, one more thing to note is that an inline function can have multiple reified type parameters and can also have non-reified type parameters alongside the reified ones. It’s important to keep in mind that marking a function as inline does not necessarily provide performance benefits in all cases. If the function becomes large, it’s recommended to extract the code that doesn’t depend on reified type parameters into separate non-inline functions for better performance.

Practical use cases of reified type parameters

Reified type parameters can be especially useful when working with APIs that expect parameters of type java.lang.Class. Let\’s explore two examples to demonstrate how reified type parameters simplify such scenarios.

Example 1

ServiceLoader The ServiceLoader API from the JDK is an example of an API that takes a java.lang.Class representing an interface or abstract class and returns an instance of a service class implementing that interface. Traditionally, in Kotlin, you would use the following syntax to load a service:

val serviceImpl = ServiceLoader.load(Service::class.java)

However, using a function with a reified type parameter, we can make this code shorter and more readable:

val serviceImpl = loadService<Service>()

To define the loadService function, we use the inline modifier and a reified type parameter:

inline fun <reified T> loadService(): T {
    return ServiceLoader.load(T::class.java)
}

Here, T::class.java retrieves the java.lang.Class corresponding to the class specified as the type parameter, allowing us to use it as needed. This approach simplifies the code by specifying the class as a type argument, which is shorter and easier to read compared to ::class.java syntax.

Example 2

Simplifying startActivity in Android In Android development, when launching activities, instead of passing the class of the activity as a java.lang.Class, you can use a reified type parameter to make the code more concise. For instance:

inline fun <reified T : Activity> Context.startActivity() {
    val intent = Intent(this, T::class.java)
    startActivity(intent)
}

With this inline function, you can start an activity by specifying the activity class as a type argument:

startActivity<DetailActivity>()

This simplifies the code by eliminating the need to pass the activity class as a java.lang.Class instance explicitly.

Reified type parameters allow us to work with class references directly, making the code more readable and concise. They are particularly useful in scenarios where APIs expect java.lang.Class parameters, such as ServiceLoader in Java or starting activities in Android.

Restrictions on Reified Type Parameters

Reified Type parameters in Kotlin have certain restrictions that you need to be aware of. Some of these restrictions are inherent to the concept itself, while others are determined by the implementation of Kotlin and may change in future Kotlin versions. Here’s a summary of how you can use reified type parameters and what you cannot do:

You can use a reified type parameter in the following ways:

Type checks and casts (is, !is, as, as?)

Reified type parameters can be used in type checks and casts. You can check if an object is of a specific type or perform a type cast using the reified type parameter. Here’s an example:

inline fun <reified T> checkType(obj: Any) {
    if (obj is T) {
        println("Object is of type T")
    } else {
        println("Object is not of type T")
    }
    
    val castedObj = obj as? T
    // Perform operations with the casted object
}

Kotlin reflection APIs (::class)

Reified type parameters can be used with Kotlin reflection APIs, such as ::class, to access runtime information about the type. It allows you to retrieve the KClass object representing the type parameter. Here’s an example:

inline fun <reified T> getTypeInformation() {
    val typeInfo = T::class
    println("Type information: $typeInfo")
}

Getting the corresponding java.lang.Class (::class.java)

Reified type parameters can also be used to obtain the corresponding java.lang.Class object of the type using the ::class.java syntax. This can be useful when interoperating with Java APIs that require Class objects. Here’s an example:

inline fun <reified T> getJavaClass() {
    val javaClass = T::class.java
    println("Java class: $javaClass")
}

Using reified type parameter as a type argument when calling other functions

Reified type parameters can be used as type arguments when calling other functions. This allows you to propagate the type information to other functions without losing it due to type erasure. Here’s an example:

inline fun <reified T> processList(list: List<T>) {
    // Process the list of type T
    for (item in list) {
        // ...
    }
}

fun main() {
    val myList = listOf("Hello", "World")
    processList<String>(myList)
}

These examples demonstrate the various ways in which reified type parameters can be utilized in Kotlin, including type checks, reflection APIs, obtaining java.lang.Class, and passing the type information to other functions as type arguments.

However, there are certain things you cannot do with reified type parameters:

Creating new instances of the class specified as a type parameter

Reified type parameters cannot be used to create new instances of the class directly. You can only access the type information using reified type parameters. To create new instances, you would need to use other means such as reflection or factory methods. Here’s an example:

inline fun <reified T> createInstance(): T {
    // Error: Cannot create an instance of the type parameter T
    return T()
}

Calling methods on the companion object of the type parameter class

Reified type parameters cannot directly access the companion object of the type parameter class. However, you can access the class itself using T::class syntax. To call methods on the companion object, you would need to access it through the class reference. Here’s an example:

inline fun <reified T> callCompanionMethod(): String {
    // Error: Cannot access the companion object of the type parameter T
    return T.Companion.someMethod()
}

Using a non-reified type parameter as a type argument

When calling a function with a reified type parameter, you cannot use a non-reified type parameter as a type argument. Reified type parameters can only be used as type arguments themselves. Here’s an example:

inline fun <reified T> reifiedFunction() {
    // Error: Non-reified type parameter cannot be used as a type argument
    anotherFunction<T>()
}

fun <T> anotherFunction() {
    // ...
}

Marking type parameters of classes, properties, or non-inline functions as reified

Reified type parameters can only be used in inline functions. You cannot mark type parameters of classes, properties, or non-inline functions as reified. Reified type parameters are limited to inline functions. Here’s an example:

class MyClass<T> {  // Error: Type parameter cannot be marked as reified
    // ...
}

val <T> List<T>.property: T  // Error: Type parameter cannot be marked as reified
    get() = TODO()

fun <T> nonInlineFunction() {  // Error: Type parameter cannot be marked as reified
    // ...
}

These examples illustrate the restrictions on reified type parameters in Kotlin. By understanding these limitations, you can use reified type parameters effectively in inline functions while keeping in mind their specific usage scenarios.

Conclusion

Reified type parameters in Kotlin offer a powerful tool for overcoming the limitations of type erasure at runtime. By utilizing reified type parameters in inline functions, developers can access and manipulate precise type information, enabling type checks, casts, and interaction with reflection APIs. Understanding the benefits and restrictions of reified type parameters empowers Kotlin developers to write more expressive, type-safe, and concise code.

By embracing reified type parameters, Kotlin programmers can unleash the full potential of generics and enhance their runtime type-related operations. Start utilizing reified type parameters today and unlock a world of type-aware programming in Kotlin!

Kotlin, a modern and versatile programming language, offers various features to enhance developer productivity. One such powerful feature is function types, which enable you to treat functions as first-class citizens in your code. In this blog post, we will delve into function types in Kotlin, understand their types, explore their usage, and provide examples to solidify our understanding. So let’s dive in!

Recap: Higher-Order Functions

In Kotlin, a higher-order function is a function that can accept a lambda expression or a function reference as an argument or can return a lambda expression or a function reference. It allows functions to be treated as values and enables flexible and concise coding.

Let’s take the example of the filter function from the standard library, which takes a predicate function as an argument and is, therefore, a higher-order function:

list.filter { x > 0 }

Function types

In Kotlin, you can declare variables with function types. This means that the variables can hold references to functions. Let’s take a look at an example:

val sum: (Int, Int) -> Int = { x, y -> x + y }  // Function that takes two Int parameters and returns an Int value
val action: () -> Unit = { println(42) }        // Function that takes no arguments and doesn’t return a value

In this code, we have two variables: sum and action. The type of sum is a function that takes two Int parameters and returns an Int. The type of action is a function that takes no parameters and returns Unit, which represents a lack of meaningful value.

What are Function Types?

Function types allow you to treat functions as values. Just like any other variable, you can assign functions to variables, pass them as parameters to other functions, and even return them from functions. This feature provides flexibility and enables you to write more concise and expressive code.

Syntax

To declare a function type, you put the function parameter types in parentheses, followed by an arrow, and the return type of the function. In the above diagram, (Int, String) -> Unit specifies a function that takes Int and String parameters and returns a Unit.

The Unit type is used to indicate that a function doesn’t return a meaningful value. In regular function declarations, you can omit the Unit return type, but in function type declarations, it is always required. So, you can’t omit a Unit in this context.

val sum: (Int, Int) -> Int = { x, y -> x + y }

In the lambda expression { x, y -> x + y }, you might notice that the types of the parameters x and y are omitted. This is because the types are already specified in the function type declaration, so there’s no need to repeat them in the lambda itself.

You can also make the return type of a function type nullable by using the? symbol. For example:

var canReturnNull: (Int, Int) -> Int? = { null }

In this case, the function type (Int, Int) -> Int? represents a function that takes two Int parameters and returns an Int that can be nullable. This means the function can return either an Int value or null.

Furthermore, you can declare a nullable variable of a function type by enclosing the entire function type definition in parentheses and placing the question mark after the parentheses. For example:

var funOrNull: ((Int, Int) -> Int)? = null

Here, ((Int, Int) -> Int)? represents a nullable variable of a function type. The entire function type definition is enclosed in parentheses, and the question mark indicates that the variable itself is nullable.

It’s important to note the distinction between a function type with a nullable return type ((Int, Int) -> Int?) and a nullable variable of a function type (((Int, Int) -> Int)?). Omitting the parentheses will result in different meanings, so be cautious when specifying nullable function types.

Parameter names of function types

In Kotlin, you have the option to specify names for the parameters of a function type. This can improve the readability of your code and can be helpful for code completion in the IDE.

Here’s an example that demonstrates specifying parameter names in a function type:

fun performRequest(url: String, callback: (code: Int, content: String) -> Unit) {
    /* ... */
}

In this code, the performRequest function takes two parameters: url of type String and callback of type (code: Int, content: String) -> Unit. The callback parameter is a function type that expects two parameters named code and content, both of type Int and String respectively. The function type represents a callback function that will be invoked when the request is completed.

When you call the performRequest function, you can provide a lambda expression as the argument for the callback parameter. The lambda can use any parameter names you prefer, regardless of the names specified in the function type declaration. For example:

val url = "https://blog.softaai.com"
performRequest(url) { code, content ->
    // Code that uses the parameters 'code' and 'content'
}

performRequest(url) { code, page ->
    // Code that uses the parameters 'code' and 'page'
}

In the above examples, we pass a lambda expression to the performRequest function. Inside the lambda, we can choose different names for the parameters (code and content in the first example, and code and page in the second example). These parameter names in the lambda expression do not need to match the names specified in the function type declaration.

Although the parameter names don’t affect type matching, using descriptive names can make your code more readable and understandable. Additionally, modern IDEs can utilize these parameter names for code completion, making it easier for you to write your code accurately.

Calling functions passed as arguments

In Kotlin, you can call functions that are passed as arguments to other functions. Let’s explore a couple of examples to understand how this works.

First, let’s consider the twoAndThree function, which takes another function as an argument and performs an arbitrary operation on the numbers 2 and 3:

fun twoAndThree(operation: (Int, Int) -> Int) {
    val result = operation(2, 3)
    println("The result is $result")
}

In this example, the twoAndThree function accepts a function called operation, which has a function type (Int, Int) -> Int. This means the operation function takes two Int parameters and returns an Int. Inside the twoAndThree function, the operation function is called with arguments 2 and 3, and the result is printed.

To call the twoAndThree function and pass a function as an argument, you can use a lambda expression. For example:

twoAndThree { a, b -> a + b }

In this case, we pass a lambda expression that adds two numbers (a + b). The lambda matches the function type (Int, Int) -> Int because it takes two Int parameters and returns an Int. The result of the addition, 5, is printed by the twoAndThree function.

Similarly, you can pass a different lambda expression to achieve a different operation:

twoAndThree { a, b -> a * b }

Here, the lambda multiplies the two numbers (a * b), and the result, 6, is printed.

The syntax for calling a function passed as an argument is the same as calling a regular function. You use parentheses after the function name and provide the necessary arguments inside the parentheses.

Now, let’s consider another example: reimplementing the filter function from the standard library. The filter function takes a predicate as a parameter. The predicate is a function that takes a character and returns a Boolean result. The implementation checks whether each character satisfies the predicate and adds it to a StringBuilder if it does.

To reimplement the filter function for strings, let’s consider the following implementation:

fun String.filter(predicate: (Char) -> Boolean): String {
    val sb = StringBuilder()
    for (index in 0 until length) {
        val element = get(index)
        if (predicate(element))
            sb.append(element)
    }
    return sb.toString()
}

In this implementation, the filter function is an extension function on the String class. It takes a predicate parameter, which is a function that takes a Char parameter and returns a Boolean.

Inside the function, a StringBuilder is created to store the filtered characters. The function iterates over each character of the string using the for loop and checks if the character satisfies the given predicate. If the predicate returns true for a character, it is appended to the StringBuilder.

Finally, the StringBuilder is converted to a string using the toString() function and returned as the result.

Here’s an example of how you can use the filter function:

println("softAai Apps".filter { it in 'A'..'Z' })

In this case, the input string is "softAai Apps", and the predicate checks if each character is within the range from 'A' to 'Z'. The filtered result, which only contains the uppercase alphabetic characters, is printed as "AA".

The filter function implementation is straightforward. It enables you to filter characters from a string based on a given predicate, providing a more convenient and readable way to perform such operations.

By using higher-order functions and passing functions as arguments, you can create flexible and reusable code that can perform different operations based on the provided functions.

Default and null values for parameters with function types

When declaring a parameter of a function type, you can specify a default value for it. This can be useful when you want to provide a default behavior for the function if the caller doesn’t provide a specific implementation. Here’s an example:

fun <T> printCollection(collection: Collection<T>, transform: (T) -> String = { it.toString() }) {
    for (element in collection) {
        println(transform(element))
    }
}

In this example, the printCollection function takes a collection parameter of type Collection<T> and a transform parameter of function type (T) -> String. The transform parameter has a default value defined as a lambda expression { it.toString() }, which uses the toString() method to convert each element of the collection to a string.

You can call the printCollection function in different ways:

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

// Omitting the transform parameter to use the default behavior
printCollection(numbers)

// Passing a lambda as the transform parameter
printCollection(numbers) { "Number: $it" }

// Passing the transform parameter as a named argument
printCollection(numbers, transform = { "Value: $it" })

In the first example, we omit the transform parameter, so the default behavior using toString() will be used to convert each element.

In the second example, we pass a lambda expression { "Number: $it" } as the transform parameter. This lambda defines a custom behavior to transform each element of the collection.

In the third example, we explicitly pass the transform parameter as a named argument, providing a different lambda expression { "Value: $it" } to customize the transformation.

Another option is to declare a parameter of a nullable function type. However, directly calling a function passed in such a parameter is not allowed because it could potentially lead to null pointer exceptions. To handle this, you can check for null explicitly or use the safe-call syntax callback?.invoke(). Here’s an example:

fun performAction(callback: (() -> Unit)?) {
    callback?.invoke()
}

In this example, the performAction function takes a nullable function type parameter callback of type (() -> Unit)?. Inside the function, we can use the safe-call syntax callback?.invoke() to invoke the function only if it is not null.

Function Types with Generic Parameters

Kotlin allows you to define function types with generic parameters. This provides flexibility when working with functions that can operate on different types.

fun <T> processList(list: List<T>, operation: (T) -> Unit) {
    for (item in list) {
        operation(item)
    }
}

val numbers = listOf(1, 2, 3, 4, 5)
processList(numbers) { println(it) } // Prints each number in the list

In the above example, the processList function takes a list of generic type T and a function type (T) -> Unit as parameters. The operation function is called for each item in the list and can perform any desired operation.

Now you know how to write functions that take functions as arguments, including how to provide default values for function parameters and handle nullable function types. This allows you to create more flexible and customizable functions in Kotlin.

Returning functions from functions

Returning functions from functions allows you to dynamically choose and provide different logic based on certain conditions or states. This can be useful in scenarios where the behavior of a program needs to adapt to different situations.

For example, let’s consider a shipping cost calculation scenario. The shipping cost may vary depending on the chosen delivery method. We can define a function called getShippingCostCalculator that takes the delivery parameter of type Delivery (an enum class representing different delivery options) and returns a function of type (Order) -> Double. The returned function calculates the shipping cost based on the selected delivery method.

Here’s an example implementation:

enum class Delivery { STANDARD, EXPEDITED }

class Order(val itemCount: Int)

fun getShippingCostCalculator(delivery: Delivery): (Order) -> Double {   // Declares a function that returns a function
    if (delivery == Delivery.EXPEDITED) {
        return { order -> 6 + 2.1 * order.itemCount }  // Returns lambdas from the function
    }
    return { order -> 1.2 * order.itemCount }     // Returns lambdas from the function
}

In this example, when getShippingCostCalculator is called with Delivery.EXPEDITED, it returns a function that takes an Order parameter and calculates the shipping cost as 6 + 2.1 * order.itemCount. For any other delivery option, it returns a different function that calculates the shipping cost as 1.2 * order.itemCount.

You can use the returned function to calculate the shipping cost for a specific order. Here’s an example of usage:

val calculator = getShippingCostCalculator(Delivery.EXPEDITED)  // Stores the returned function in a variable
println("Shipping costs ${calculator(Order(3))}")   // Invokes the returned function

In this code, we obtain the calculator function by calling getShippingCostCalculator with Delivery.EXPEDITED. Then, we pass an Order object with itemCount as 3 to the calculator function, which calculates and returns the shipping cost as 12.3. Finally, we print the shipping cost.

Let’s consider one more scenario where returning functions from functions is useful.

Suppose you’re working on a GUI contact-management application, and you need to determine which contacts should be displayed based on the state of the user interface (UI). You can define a function called getContactFilter that takes a UI state as a parameter and returns a function of type (Contact) -> Boolean. The returned function will determine whether a contact should be displayed or not based on the UI state.

Here’s an example implementation:

data class Contact(val name: String, val isFavorite: Boolean)

enum class UIState { ALL, FAVORITES }

fun getContactFilter(uiState: UIState): (Contact) -> Boolean {  // Declares a function that returns a function
    return when (uiState) {
        UIState.ALL -> { true } // Display all contacts
        UIState.FAVORITES -> { contact -> contact.isFavorite } // Display only favorite contacts
    }
}

In this example, getContactFilter takes a UIState parameter and returns a function of type (Contact) -> Boolean. The returned function determines whether a contact should be displayed or not based on the UI state. If the UI state is UIState.ALL, the returned function always returns true, indicating that all contacts should be displayed. If the UI state is UIState.FAVORITES, the returned function checks the isFavorite property of the contact and returns its value, indicating whether the contact is a favorite or not.

You can use the returned function to filter the contacts based on the UI state. Here’s an example usage:

val filter = getContactFilter(UIState.FAVORITES)
val contacts = listOf(
    Contact("amol pawar", true),
    Contact("atul tele", false),
    Contact("akshay pawal", true)
)
val filteredContacts = contacts.filter(filter)
println("Filtered Contacts:")
filteredContacts.forEach { println(it.name) }

In this code, we obtain the filter function by calling getContactFilter with UIState.FAVORITES. Then, we have a list of contacts, and we use the filter function to filter the contacts based on the UI state. The filtered contacts, in this case, are the contacts that are marked as favorites. Finally, we print the names of the filtered contacts.

Returning functions from functions allows you to dynamically select and apply different logic based on conditions or states, providing flexibility and customization in your code.

Using function types from Java

Under the hood, function types are declared as regular interfaces: a variable of a function type is an implementation of a FunctionN interface. The Kotlin standard library defines a series of interfaces, corresponding to different numbers of function arguments: Function0 (this function takes no arguments), Function1 (this function takes one argument), and so on. Each interface defines a single invoke method, and calling it will execute the function. A variable of a function type is an instance of a class implementing the corresponding FunctionN interface, with the invoke method containing the body of the lambda.

Kotlin functions that use function types can be called easily from Java. Java 8 lambdas are automatically converted to values of function types:

/* Kotlin declaration */
fun processTheAnswer(f: (Int) -> Int) {
    println(f(42))
}

// Java
processTheAnswer(number -> number + 1);  // output : 43

In this case, the processTheAnswer function in Kotlin takes a function type (Int) -> Int as a parameter. In Java, you can pass a lambda expression number -> number + 1 as an argument, and it will be automatically converted to the corresponding function type.

What about older Java versions?

If you are using an older version of Java that doesn’t support lambdas, you can pass an instance of an anonymous class that implements the invoke method from the corresponding function interface. Here’s an example:

// Java
processTheAnswer(new Function1<Integer, Integer>() {    // Uses the Kotlin function type from Java code (prior to Java 8)
    @Override
    public Integer invoke(Integer number) {
        System.out.println(number);
        return number + 1;
    }
});

In this Java example, we create an anonymous class that implements the Function1 interface. We override the invoke method, which corresponds to the function body in Kotlin, and provide the desired implementation.

What about Extention Functions?

In Java, you can easily use extension functions from the Kotlin standard library that expect lambdas as arguments. Note, however, that they don’t look as nice as in Kotlin — you have to pass a receiver object as a first argument explicitly. Here’s an example:

// Java
List<String> strings = new ArrayList<>();
strings.add("42");
CollectionsKt.forEach(strings, s -> {
    System.out.println(s);
    return Unit.INSTANCE;
});

In this Java example, we use the CollectionsKt.forEach extension function from the Kotlin standard library. We pass a lambda expression s -> { ... } as an argument. Inside the lambda, we can perform the desired operations. Note that in Java, you need to explicitly return Unit.INSTANCE to match the Kotlin requirement of returning Unit.

It’s important to remember that in Java, functions or lambdas can return Unit. However, since Unit has a value in Kotlin, you need to explicitly return it. Additionally, you cannot directly pass a lambda that returns void as an argument of a function type that expects Unit as the return type.

Overall, while using function types and lambdas from Kotlin in Java may require some adjustments in syntax, it is still possible to utilize Kotlin’s higher-order functions and achieve the desired functionality.

Removing duplication through lambdas

In Kotlin, lambdas are anonymous functions that can be treated as values. They allow you to define blocks of code that can be passed around and executed later. This flexibility enables us to write more concise and reusable code.

Suppose you have a scenario where you need to perform similar operations on different elements of a collection. Without lambdas, you might end up writing repetitive code for each element, resulting in duplication. However, by utilizing lambdas, you can extract the common behavior and eliminate duplication.

To illustrate this concept, let’s consider an example involving website visit data. We have a class called SiteVisit that represents a visit to a website. Each visit has properties like path (the visited URL), duration (time spent on the page), and os (operating system used by the visitor). The os property is an enum called OS, representing different operating systems.

data class SiteVisit(
    val path: String,
    val duration: Double,
    val os: OS
)

enum class OS { WINDOWS, LINUX, MAC, IOS, ANDROID }

Now, let’s say we have a list of SiteVisit objects called log, which contains information about various visits to the website.

val log = listOf(
    SiteVisit("/", 34.0, OS.WINDOWS),
    SiteVisit("/", 22.0, OS.MAC),
    SiteVisit("/login", 12.0, OS.WINDOWS),
    SiteVisit("/signup", 8.0, OS.IOS),
    SiteVisit("/", 16.3, OS.ANDROID)
)

Our goal is to calculate the average duration of visits from Windows machines. We can achieve this by filtering the visits based on the operating system, mapping the durations, and then calculating the average using the average function.

val averageWindowsDuration = log
    .filter { it.os == OS.WINDOWS }
    .map(SiteVisit::duration)
    .average()

println(averageWindowsDuration) // Output: 23.0

In this example, we used the lambda expression { it.os == OS.WINDOWS } as a filter to select only the visits with the Windows operating system. Then, we used the map function to extract the durations of those visits. Finally, the average function calculated the average duration.

Now, let’s say we want to calculate the average duration for visits from Mac users as well. Without using lambdas, we would need to write similar code again, resulting in duplication. However, we can avoid this duplication by extracting the common behavior into a function and parameterizing it.

We define an extension function called averageDurationFor on the List<SiteVisit> class, which takes an os parameter representing the operating system. Inside the function, we filter the visits based on the given operating system, map the durations, and calculate the average.

fun List<SiteVisit>.averageDurationFor(os: OS) =
    filter { it.os == os }
        .map(SiteVisit::duration)
        .average()

With this function in place, we can now calculate the average duration for both Windows and Mac visits without duplicating the code.

println(log.averageDurationFor(OS.WINDOWS)) // Output: 23.0
println(log.averageDurationFor(OS.MAC)) // Output: 22.0

By parameterizing the behavior that varies (in this case, the operating system), we eliminated duplication and made the code more reusable and maintainable.

However, there are situations where a simple parameter is not sufficient to capture the complexity of the condition we want to apply. For example, if we want to calculate the average duration for visits from mobile platforms (iOS and Android), a single parameter representing the operating system won’t be enough. In such cases, lambdas provide a powerful solution.

We can modify our averageDurationFor function to take a lambda expression as a parameter. This lambda expression represents a condition that needs to be fulfilled for a visit to be included in the calculation.

fun List<SiteVisit>.averageDurationFor(predicate: (SiteVisit) -> Boolean) =
    filter(predicate)
        .map(SiteVisit::duration)
        .average()

Now, we can use this enhanced averageDurationFor function to calculate the average duration based on more complex conditions. For example, finding the average duration for visits from Android and iOS users:

println(log.averageDurationFor { it.os in setOf(OS.ANDROID, OS.IOS) }) // Output: 12.15

In this case, we passed a lambda expression { it.os in setOf(OS.ANDROID, OS.IOS) } to the averageDurationFor function. This lambda expression represents the condition that checks if the operating system is either Android or iOS.

Similarly, we can use Lambdas to perform more intricate queries, such as finding the average duration of visits to the signup page from iOS users:

println(log.averageDurationFor { it.os == OS.IOS && it.path == "/signup" }) // Output: 8.0

Here, we provided a lambda expression { it.os == OS.IOS && it.path == "/signup" } to specify the condition that includes only the visits from iOS users to the “/signup” page.

By using lambdas and function types, we can eliminate code duplication and extract both the repeated data and behavior into reusable functions. Lambdas allow us to write more expressive and concise code, making our programs easier to understand and maintain.

Function types and lambdas not only help eliminate code duplication but also provide a flexible and concise way to define different strategies or behaviors within your code. Instead of creating multiple classes or interfaces for each strategy, you can directly pass lambda expressions as different strategies, simplifying your code and making it more expressive.

Conclusion

Function types in Kotlin provide a powerful way to work with functions as first-class citizens. They enable you to pass functions as parameters, return them from functions, and even assign them to variables. This flexibility allows for concise and expressive code, making Kotlin a great language for functional programming paradigms. By understanding the various aspects of function types and exploring practical examples, you can leverage this feature to write more efficient and maintainable code. So go ahead, harness the power of function types in Kotlin, and take your programming skills to the next level!

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.

Kotlin, being a modern and expressive programming language, provides a set of conventions that allow developers to use specific language constructs by defining functions with predefined names. These conventions provide a consistent and intuitive way to work with various language features. In this article, we’ll explore the different aspects of conventions in Kotlin and provide in-depth explanations along with examples.

Kotlin Conventions

As you know, Java has several language features tied to specific classes in the standard library. For example, objects that implement java.lang.Iterable can be used in for loops, and objects that implement java.lang.AutoCloseable can be used in try-with-resources statements. Kotlin has a number of features that work in a similar way, where specific language constructs are implemented by calling functions that you define in your own code. But instead of being tied to specific types, in Kotlin those features are tied to functions with specific names. For example, if your class defines a special method named plus, then, by convention, you can use the + operator on instances of this class. Because of that, in Kotlin we refer to this technique as conventions.

Kotlin uses the principle of conventions, instead of relying on types as Java does, because this allows developers to adapt existing Java classes to the requirements of Kotlin language features. The set of interfaces implemented by a class is fixed, and Kotlin can’t modify an existing class so that it would implement additional interfaces. On the other hand, defining new methods for a class is possible through the mechanism of extension functions. You can define any convention methods as extensions and thereby adapt any existing Java class without modifying its code

BTW, conventions in Kotlin are not limited to operator overloading or extension functions. There are various predefined function names that, when implemented in your class, enable specific language constructs and provide additional functionality. Here are a few examples:

1. iterator: By implementing the iterator function, you enable the usage of your class in for loops, similar to how objects implementing java.lang.Iterable work in Java.
2. invoke: Defining the invoke function allows you to treat instances of your class as function-like objects. This means you can call objects of your class as if they were functions directly, like myObject(parameter).
3. compareTo: If you implement the compareTo function, you can use comparison operators (<, <=, >, >=) on instances of your class, allowing for natural ordering.
4. Destructuring Declarations: Kotlin provides the ability to destructure objects into multiple variables using the component1(), component2(), etc. functions. By implementing these functions in your class, you can use destructuring declarations with instances of your class.

These are just a few examples of Kotlin conventions. By defining functions with specific names in your class, you can harness the power of Kotlin’s language features and make your code more expressive and concise. Kotlin conventions simplify the process of working with common language constructs and operators, promoting code readability and reducing boilerplate. Let’s go through each topic step by step.

Overloading arithmetic operators

As we see earlier, the most straightforward example of the use of conventions in Kotlin is arithmetic operators. In Java, the full set of arithmetic operations can be used only with primitive types, and additionally, the + operator can be used with String values. But these operations could be convenient in other cases as well. For example, if you’re working with numbers through the BigInteger class, it’s more elegant to sum them using + than to call the add method explicitly. To add an element to a collection, you may want to use the += operator. Kotlin allows you to do that, and in the below section, we’ll see how it works.

Overloading binary arithmetic operations

In Kotlin, you can overload binary arithmetic operations by defining functions with the corresponding operator modifier. That means Arithmetic operators, such as +, -, *, /, and %, can be overloaded in Kotlin. To overload an arithmetic operator, you need to define a function with a specific name and annotate it with the operator keyword. Let’s take the example of overloading the plus operator for the Point class.

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

You can define the plus function within the Point class as follows:

data class Point(val x: Int, val y: Int) {
    operator fun plus(other: Point): Point {
        return Point(x + other.x, y + other.y)
    }
}

Note that the operator keyword is used to declare the plus function. This explicitly indicates that you intend to use the function as an implementation of the + operator convention.

Once you have declared the plus function as an operator, you can use the + sign to sum up instances of the Point class:

val point1 = Point(1, 2)
val point2 = Point(3, 4)
val sum = point1 + point2
println(sum) // Output: Point(x=4, y=6)

The point1 + point2 expression is equivalent to point1.plus(point2). The plus function is called automatically when the + operator is used between two Point instances.

Under the hood, when you use the + operator, the plus function is automatically invoked to perform the addition.

Alternatively, you can define the plus operator function as an extension function outside the Point class:

operator fun Point.plus(other: Point): Point {
    return Point(x + other.x, y + other.y)
}

The implementation of the operator function remains the same, but it is now defined as an extension function.

Lists of all the binary operators you can define and the corresponding function names:

You can overload other arithmetic operators in a similar way by defining corresponding functions (minus, times, div, rem, etc.) within your class.

It’s important to note that the precedence of Kotlin operators follows the same rules as the standard numeric types. For example, in an expression like a + b * c, the multiplication (*) will always be executed before the addition (+), regardless of how you have defined those operators, even if you’ve defined those operators yourself. The operators *, /, and % have the same precedence, which is higher than the precedence of the + and — operators

Kotlin operators do not automatically support commutativity, which means you need to define separate operators if you want to swap the order of the operands. For example

operator fun Point.times(scale: Double): Point {
    return Point((x * scale).toInt(), (y * scale).toInt())
}

val p = Point(10, 20)
println(p * 1.5)   // Point(x=15, y=30)

Now suppose If you want users to be able to write 1.5 * p in addition to p * 1.5, you need to define a separate operator for that:

operator fun Double.times(p: Point): Point

Furthermore, The return type of an operator function can also be different from either of the operand types. For example, you can define an operator to create a string by repeating a character a number of times.

operator fun Char.times(count: Int): String {<br>return toString().repeat(count)<br>}<br><br>println('a' * 3)   // aaa

This operator takes a Char as the left operand and an Int as the right operand and has String as the result type. Such combinations of operand and result types are perfectly acceptable.

Note that you can overload operator functions like regular functions: you can define multiple methods with different parameter types for the same method name.

Java Interoperability (Operator Functions and Java)

When it comes to calling Kotlin operator functions from Java, it is straightforward. Since each overloaded operator in Kotlin is defined as a function, you can call them from Java just like regular functions by using the full function name.

For example, let’s say you have a Kotlin class Point with an overloaded plus operator function:

  data class Point(val x: Int, val y: Int) {
    operator fun plus(other: Point): Point {
        return Point(x + other.x, y + other.y)
    }
}

In Java, you would call this operator function as a regular function using the fully qualified name:

Point point1 = new Point(1, 2);
Point point2 = new Point(3, 4);
Point sum = point1.plus(point2);

Since Java doesn’t have a specific syntax for operator functions like Kotlin does, you need to call the operator function using the actual function name (plus in this case) instead of the operator symbol (+).

Now when calling Java from Kotlin, you can use the operator syntax for methods that match Kotlin conventions. Kotlin provides syntactic sugar to make code more concise and expressive. For example, if you have a Java class with a method named add and you call it from Kotlin, you can use the + operator instead, as long as the method follows the conventions of the plus operator in Kotlin.

On the other hand, if a Java class defines a method with the desired behavior but with a different name, you can define an extension function in Kotlin with the correct name that delegates to the existing Java method. This allows you to bridge the gap between Kotlin’s operator conventions and Java’s method names.

So, when interacting between Kotlin and Java, Kotlin operator functions can be called from Java as regular functions using their fully qualified names. In the reverse scenario, when calling Java from Kotlin, you can use the operator syntax for methods that adhere to Kotlin’s conventions, and you have the flexibility to define extension functions in Kotlin to map to existing Java methods with different names.

No special operators for bitwise operations

In Kotlin, there are no special operators for bitwise operations on standard number types. Instead, regular functions with infix call syntax are used to perform bitwise operations. You can also define similar functions that work with your own types.

Kotlin provides a set of functions for performing bitwise operations, including:

• shl (Signed shift left): Performs a signed shift left operation.
• shr (Signed shift right): Performs a signed shift right operation.
• ushr (Unsigned shift right): Performs an unsigned (logical) shift right operation.
• and (Bitwise and): Performs a bitwise and operation.
• or (Bitwise or): Performs a bitwise or operation.
• xor (Bitwise xor): Performs a bitwise exclusive or operation.
• inv (Bitwise inversion): Performs a bitwise inversion operation.

Here’s an example demonstrating the use of some of these functions:

println(0x0F and 0xF0)   // Bitwise and operation: 00001111 and 11110000 = 00000000 (result: 0)
println(0x0F or 0xF0)    // Bitwise or operation:  00001111 or  11110000 = 11111111 (result: 255)
println(0x1 shl 4)       // Signed shift left operation: 00000001 shifted left by 4 positions = 00010000 (result: 16)

In the above example, and performs a bitwise and operation between 0x0F (00001111) and 0xF0 (11110000), resulting in 0 (00000000). or performs a bitwise or operation between the same values, resulting in 255 (11111111). shl shifts 0x1 (00000001) left by 4 positions, resulting in 16 (00010000).

It’s important to note that while Kotlin doesn’t provide special operators for bitwise operations, you can use these functions to achieve the desired functionality. Additionally, you can define similar functions for your own types if needed.

Overloading compound assignment operators

In Kotlin, compound assignment operators such as +=, -=, and so on, are supported for certain operations. These operators allow you to modify a variable by performing an operation and assigning the result back to the variable in a single step.

When you define an operator, such as plus, Kotlin automatically supports the corresponding compound assignment operator, such as +=.

However, there can be ambiguity when both the regular operator function and the compound assignment operator function are applicable.

To illustrate, let’s consider the example of the plusAssign function defined for a mutable collection in the Kotlin standard library:

operator fun <T> MutableCollection<T>.plusAssign(element: T) {
    this.add(element)
}

When you use the += operator with a mutable collection, the plusAssign function is called. It adds an element to the collection.

In some cases, there may be ambiguity between using the regular operator or the compound assignment operator. When both the regular operator function (e.g., plus) and the compound assignment operator function (e.g., plusAssign) are applicable, Kotlin needs to decide which one to use.

To resolve this ambiguity, there are a few options:

1. Replace the use of the operator with a regular function call that explicitly states the intention. For example, instead of using +=, you can use the add function directly: collection.add(element).
2. Change a var to a val to make the compound assignment operation inapplicable. If the variable is read-only (val), the compound assignment operator cannot modify its value.
3. Design your classes consistently by providing either the regular operator function or the compound assignment operator function, but not both. If your class is immutable, like the Point class in an earlier example, it\’s best to provide operations that return a new value (e.g., plus). On the other hand, if your class is mutable, like a builder, it\’s best to provide operations like plusAssign that modify the instance in place.

It’s important to note that the Kotlin standard library supports both approaches for collections. The + and - operators always return a new collection. The += and -= operators work on mutable collections by modifying them in place and on read-only collections by returning a modified copy. However, it\’s worth mentioning that += and -= can only be used with a read-only collection if the variable referencing it is declared as a varand not as a val.

val readOnlyList = listOf(1, 2, 3)
var mutableList = mutableListOf(4, 5, 6)

mutableList += readOnlyList
println(mutableList) // Output: [4, 5, 6, 1, 2, 3]

readOnlyList += mutableList // Error: Val cannot be reassigned

In the above example, we have a read-only list readOnlyList and a mutable list mutableList. The += operator can be used to add the elements of readOnlyList to mutableList because mutableList is declared as a var. However, when we try to use += on readOnlyList, it throws an error because readOnlyList is declared as a val and cannot be reassigned.

So, to use += and -= operators on a read-only collection, make sure the variable referencing it is declared as a mutable variable (var). If it is declared as an immutable variable (val), you won\’t be able to modify the collection using these operators.

In Kotlin, when using the += and -= operators on collections, you can provide either individual elements or other collections as operands. The important thing is that the elements or collections you use should have a matching element type with the collection you are modifying.

val numbers = mutableListOf(1, 2, 3)
numbers += 4
println(numbers) // Output: [1, 2, 3, 4]

val list1 = listOf(1, 2, 3)
val list2 = listOf(3, 4, 5)

val combinedList = list1 + list2
println(combinedList) // Output: [1, 2, 3, 3, 4, 5]

It’s important to note that when using collections as operands, the element types should match. In the above example, both list1 and list2 contain integers, so the operations work seamlessly. If the element types don\’t match, such as combining a list of integers with a list of strings, you will encounter a compilation error.

Overloading unary operators

Kotlin allows you to overload unary operators, which are applied to a single value, as in -a. You can overload unary operators such as unary minus (-) and increment/decrement (++ and --) by declaring a function with a predefined name and marking it with the operator modifier.

Let’s start with the unary minus operator. To overload the unary minus operator for a class, you can define a function named unaryMinus without any parameters. This function should negate the coordinates of the object and return it.

data class Point(val x: Int, val y: Int) {
    operator fun unaryMinus(): Point {
        return Point(-x, -y)
    }
}

In the above example, the unaryMinus function negates the coordinates of the Point object and returns a new Point with negated values.

Next, let’s consider the increment and decrement operators (++ and --). When you define the inc and dec functions to overload these operators, the compiler automatically supports the same semantics as for regular number types, including both pre-increment and post-increment operations.

Here’s an example that demonstrates the use of pre-increment and post-increment operators:

data class Counter(var value: Int) {
    operator fun inc(): Counter {
        value++
        return this
    }
    
    operator fun dec(): Counter {
        value--
        return this
    }
}

fun main() {
    var counter = Counter(0)
    println(counter++) // Post-increment: prints the current value (0)
    println(++counter) // Pre-increment: increments and then prints the new value (2)
}

In the above example, the inc function overloads the ++ operator for the Counter class. It increments the value property and returns the updated Counter object. Similarly, the dec function overloads the -- operator for decrementing.

When the increment or decrement operator is used, the semantics depend on whether it is used before or after the operand. The post-increment operator (counter++) evaluates the expression and then increments the value. The pre-increment operator (++counter) increments the value and then evaluates the expression.

Overloading comparison operators

In Kotlin, you can overload comparison operators (such as ==, !=, >, <, >=, <=) for any object, not just for primitive types. This allows for intuitive and concise comparisons.

Equality operators: “equals”

Using the == operator in Kotlin is translated into a call of the equals method, also using the != operator is also translated into a call of equals, with the obvious difference that the result is inverted.

Equality operators (== and !=) can be used with nullable operands because they check for equality to null internally. When using the comparison a == b, it checks whether a is not null and, if it\’s not, calls a.equals(b). If both arguments are null references, the result is true.

To check if two objects refer to the same instance, you can use the identity equals operator (===). It behaves similarly to the == operator in Java and checks if both arguments reference the same object. However, note that the === operator cannot be overloaded.

The equals function is used to implement the equality comparison. It is marked as override because it is defined in the Any class, which is the base class for all objects in Kotlin. You don\’t need to mark it as an operator because the base method in Any is already marked as such, and the operator modifier applies to all methods that implement or override it. It is important to note that equals cannot be implemented as an extension function since the inherited implementation from Any would always take precedence over the extension.

Ordering operators: compareTo

For ordering operators (<, >, <=, >=), Kotlin supports the Comparable interface. The compareTo method defined in this interface can be called by convention, and the usage of comparison operators is translated into calls to compareTo. The return type of compareTo must be Int. For example, the expression p1 < p2 is equivalent to p1.compareTo(p2) < 0. Other comparison operators work in a similar way.

Here’s an example of implementing the compareTo function for a Person class, using address book ordering:

data class Person(val firstName: String, val lastName: String) : Comparable<Person> {
    override fun compareTo(other: Person): Int {
        return if (lastName != other.lastName) {
            lastName.compareTo(other.lastName)
        } else {
            firstName.compareTo(other.firstName)
        }
    }
}

fun main() {
    val person1 = Person("Amol", "Pawar")
    val person2 = Person("Govind", "Rakhonde")

    println(person1 < person2) // true
    println(person1 > person2) // false
}

In the above example, the compareTo function compares Person objects based on their last names first. If the last names are the same, it compares based on their first names. The Comparable interface is implemented to enable comparisons using the concise operator syntax.

It’s important to note that you don’t need to add any extensions to compare Java classes that implement the Comparable interface.

println("abc" < "bac") //true

Kotlin supports the operator syntax for these comparisons out of the box.

Conventions used for collections and ranges

Some of the most common operations for working with collections are getting and setting elements by index, as well as checking whether an element belongs to a collection. All of these operations are supported via operator syntax: To get or set an element by index, you use the syntax a[i] (called the index operator). The in operator can be used to check whether an element is in a collection or range and also to iterate over a collection. You can add those operations for your own classes that act as collections. Let’s now look at the conventions used to support those operations.

Accessing elements by index: “get” and “set”

In Kotlin, you can access and modify values in a map or a custom class using the indexing operator [] and the set function. Let\’s look at how to implement these conventions:

Implementing the get operator:

• To access a value from a map using the indexing operator, you can define the get function in your class.
• The get function takes the key as a parameter and returns the corresponding value.
• You can define the get function with a single parameter of the key type and mark it as operator.
• Inside the get function, you can handle different cases based on the key value and return the appropriate result.

operator fun Point.get(index: Int): Int {
    return when (index) {
        0 -> x
        1 -> y
        else -> throw IndexOutOfBoundsException("Invalid coordinate $index")
    }
}

Implementing the set operator:

• To change the value for a key in a mutable map or a custom class, you can define the set function.
• The set function takes the key and the new value as parameters and updates the corresponding value.
• You can define the set function with two parameters (index and value) and mark it as operator.
• Inside the set function, you can handle different cases based on the index and update the value accordingly.

operator fun MutablePoint.set(index: Int, value: Int) {
    when (index) {
        0 -> x = value
        1 -> y = value
        else -> throw IndexOutOfBoundsException("Invalid coordinate $index")
    }
}

With these implementations, you can use the indexing operator [] on objects of your class to access or modify specific values. For example:

val p = Point(5, 10)

val xCoordinate = p[0] // Accessing the x-coordinate of Point using the indexing operator

p[1] = 20 // Modifying the y-coordinate of Point using the indexing operator

val mutableP = MutablePoint(3, 7)

mutableP[0] = 15 // Modifying the x-coordinate of MutablePoint using the indexing operator

By adhering to the conventions and implementing the get and set functions, you enable the use of square brackets for element access and modification, providing a familiar and intuitive syntax for working with maps or custom collection-like classes.

The “in” convention

In Kotlin, the in operator is used to check whether an object belongs to a collection or range. The corresponding function for the in operator is contains. Here’s how you can use the in operator and implement the contains function:

Using the in operator:

• The object on the right side of the in operator is the object on which the contains method will be called.
• The object on the left side of the in operator becomes the argument passed to the contains method.
• The in operator returns a Boolean value indicating whether the object is present in the collection or range.

val list = listOf(1, 2, 3, 4, 5)
val number = 3
val isInList = number in list // Checking if number is in the list

val range = 1..10
val point = 7
val isInRange = point in range // Checking if point is in the range

Implementing the contains function:

• If you want to use the in operator with custom classes, you need to implement the contains function in your class.
• The contains function takes a single parameter that represents the object being checked for membership.
• Inside the contains function, you can define the logic to determine whether the object is present in the collection or range.
• The function should return a Boolean value indicating the result of the membership check.

data class Rectangle(val left: Int, val top: Int, val right: Int, val bottom: Int) {
    operator fun Rectangle.contains(p: Point): Boolean {
        return p.x in upperLeft.x until lowerRight.x && p.y in upperLeft.y until lowerRight.y
    }
}

val rect = Rectangle(Point(10, 20), Point(50, 50))
println(Point(20, 30) in rect)  // true
println(Point(5, 5) in rect)   // false

In the Rectangle class, the contains function checks if a given Point falls within the range of the rectangle. By using the open range (until), the condition point.x in left until right ensures that the x coordinate of the point is greater than or equal to left but less than right. Similarly, the condition point.y in top until bottom checks if the y coordinate of the point is greater than or equal to top but less than bottom.

In the implementation of Rectangle .contains, you used the until standard library function to build an open range and then you use the in operator on a range to check that a point belongs to it.

An open range is a range that doesn’t include its ending point. For example, if you build a regular (closed) range using 10..20, this range includes all numbers from 10 to 20, including 20. An open range 10 until 20 includes numbers from 10 to 19 but doesn’t include 20. A rectangle class is usually defined in such a way that its bottom and right coordinates aren’t part of the rectangle, so the use of open ranges is appropriate here.

The rangeTo convention

To create a range in Kotlin, you can use the .. syntax. For example, 1..10 represents a range that includes all the numbers from 1 to 10. This syntax is a concise way to call the rangeTo function, which returns a range.

The rangeTo function is defined in the Kotlin standard library and can be called on any comparable element. It has the following signature:

operator fun <T: Comparable<T>> T.rangeTo(that: T): ClosedRange<T>

This function returns a ClosedRange that allows you to check whether different elements belong to it.

Here’s an example of how you can use the rangeTo function to create a range:

import java.time.LocalDate

fun main() {
    val now = LocalDate.now()
    val futureRange = now.rangeTo(now.plusDays(10))

    for (date in futureRange) {
        println(date)
    }
}

In this example, now.rangeTo(now.plusDays(10)) creates a range of LocalDate objects from the current date (now) to 10 days in the future. The range includes both the starting and ending dates. The rangeTo function isn’t a member of LocalDate but rather is an extension function on Comparable.

When using the rangeTo operator, it\’s recommended to use parentheses to clearly separate the range expression from other operations. For example:

val range = (start..end).step(2)

Additionally, if you want to call a method on a range, make sure to surround the range expression with parentheses to avoid compilation errors. For example:

(0..n).forEach { print(it) }

By using parentheses, you ensure that the forEach method is called on the range expression (0..n).

The “iterator” convention for the “for” loop

In Kotlin, the for loop uses the in operator for iteration. The meaning of the in operator in this context is different from its use with ranges. Here it is used to perform an iteration over a collection or a range.

When you write a for loop like for (x in list) { ... }, it is translated into a call to the iterator() method on the list object. This method returns an iterator on which the hasNext() and next() methods are called repeatedly to iterate over the elements of the collection.

The iterator() method can be defined as an extension function in Kotlin, which explains why you can iterate over a regular Java string. The Kotlin standard library provides an extension function iterator() on CharSequence, which is a superclass of String. It returns a CharIterator that allows iterating over the characters of the string.

operator fun CharSequence.iterator(): CharIterator<br><br>// for (c in "resume sender app") {}

Here’s an example that demonstrates iterating over a custom range type, ClosedRange<LocalDate>:

operator fun ClosedRange<LocalDate>.iterator(): Iterator<LocalDate> =
    object : Iterator<LocalDate> {
        var current = start

        override fun hasNext() = current <= endInclusive

        override fun next() = current.apply { current = plusDays(1) }
    }
}

fun main() {
    val newYear = LocalDate.ofYearDay(2017, 1)
    val daysOff = newYear.minusDays(1)..newYear

    for (dayOff in daysOff) {
        println(dayOff)
    }
}


// OUTPUT
// 2016-12-31
// 2017-01-01 

In this example, the ClosedRange<LocalDate> type is extended with the iterator() method, which returns a custom iterator implementation. The iterator starts from the start date and increments by one day until it reaches the endInclusive date.

The daysOff range represents the day before and New Year day. The for loop then iterates over the dates in the range, printing each day off.

Note how you define the iterator method on a custom range type: you use LocalDate as a type argument. The rangeTo library function, shown in the previous section, returns an instance of ClosedRange, and the iterator extension on ClosedRange allows you to use an instance of the range in a for loop.

By defining the iterator() extension function on a custom range type, you can use an instance of the range in a for loop to perform iteration.

Destructuring declarations and component functions

Destructuring declarations in Kotlin allow you to unpack a single composite value and initialize multiple separate variables with its contents. Here’s how it works:

1. Destructuring declarations look like regular variable declarations, but with multiple variables grouped in parentheses.
2. Under the hood, the principle of conventions is used. To initialize each variable in a destructuring declaration, a function named componentN is called, where N is the position of the variable in the declaration.

For data classes, the compiler automatically generates componentN functions for every property declared in the primary constructor. However, for non-data classes, you need to manually define these functions. Here\’s an example:

class Point(val x: Int, val y: Int) {
    operator fun component1() = x
    operator fun component2() = y
}

In the example above, the Point class has two properties, x and y. The component1() function returns the value of x, and the component2() function returns the value of y. These functions enable destructuring declarations to work with instances of the Point class.

One of the main use cases for destructuring declarations is returning multiple values from a function. You can define a data class to hold the values you want to return and use it as the return type of the function. The destructuring declaration syntax allows you to easily unpack and use the returned values. Let’s take an example of splitting a filename into a name and an extension:

data class NameComponents(val name: String, val extension: String)

fun splitFilename(fullName: String): NameComponents {
    val (name, extension) = fullName.split('.', limit = 2)
    return NameComponents(name, extension)
}

In the splitFilename function, the fullName is split into a list of two elements: the name and the extension. The destructuring declaration val (name, extension) = ... allows us to directly assign these values to the name and extension variables. The function then returns an instance of the NameComponents data class.

Of course, it’s not possible to define an infinite number of such componentN functions so the syntax would work with an arbitrary number of items, but that wouldn’t be useful, either. The standard library allows you to use this syntax to access the first five elements of a container

If you need to return more than two or three values, Kotlin provides the Pair and Triple classes from the standard library. These classes allow you to package multiple values together without defining your own custom class. However, using custom data classes is generally preferred as they provide better clarity about the contained values.

Destructuring declarations and loops

Destructuring declarations can be used not only as top-level statements in functions but also in other places where variable declarations are allowed, such as loops. One useful application is when iterating over entries in a map. Here’s an example that demonstrates this syntax by printing all entries in a given map:

fun printEntries(map: Map<String, String>) {
    for ((key, value) in map) {
        println("$key -> $value")
    }
}

val map = mapOf("resume app" to "Resume Sender App", "kids app" to "ABC123Learn App")
printEntries(map)

// OUTPUT 
// resume app -> Resume Sender App
// kids app -> ABC123Learn App

In this example, the printEntries function takes a Map as input. The for loop uses a destructuring declaration (key, value) to unpack each entry in the map. The key variable will hold the key of the current entry, and the value variable will hold the corresponding value. The body of the loop then prints the key-value pair.

Under the hood, Kotlin provides two conventions for achieving this behavior. First, the Kotlin standard library includes an extension function called iterator on the Map interface, which returns an iterator over the map entries. This allows you to iterate directly over the map in a loop.

Second, the Map.Entry interface, representing a key-value pair in the map, has extension functions component1 and component2. These functions return the key and value, respectively, of the Map.Entry instance. The destructuring declaration in the loop internally calls these functions to assign the key and value to the declared variables.

In essence, the loop using destructuring declarations is equivalent to the following code:

for (entry in map.entries) {
    val key = entry.component1()
    val value = entry.component2()
    // ...
}

This example highlights the significance of extension functions in Kotlin conventions. The extension functions iterator, component1, and component2 enable the concise and readable syntax for iterating over map entries and accessing their key-value pairs.

Conclusion

Conventions in Kotlin provide a powerful way to customize the behavior of language constructs and enhance code readability. By leveraging operator overloading and following function naming conventions, you can create expressive and intuitive APIs. Understanding and utilizing these conventions will help you write clean, concise, and idiomatic Kotlin code.

In this article, we covered various aspects of conventions in Kotlin, including operator overloading conventions for arithmetic operations, comparison operators, indexing, and containment. We also explored Conventions used for collections and ranges and Destructuring declarations.

Remember to practice using conventions in your Kotlin projects to improve code quality and maintainability. Happy coding!

Kotlin offers various powerful features to make code concise and efficient. One such feature is delegation, which allows you to delegate the implementation of properties or functions to another object. This concept of delegation plays a crucial role in achieving code reuse, separation of concerns, and enhancing the readability and maintainability of your code. In this blog, we will explore Kotlin delegation and delve into the details of delegated properties.

Delegated properties allow you to leverage the power of trusted helper objects called delegates. These delegates handle complex tasks, freeing up your properties to focus on their core responsibilities. From database tables to browser sessions and maps, the possibilities are endless.

Join me as we embark on this thrilling journey, exploring the art of delegation and unlocking the true potential of Kotlin delegation properties. Get ready to witness the magic as your properties become extraordinary with just a touch of delegation!

Understanding Kotlin Delegation

Delegation in programming is a design pattern where an object, known as the delegate, is given the responsibility to handle certain tasks or operations on behalf of another object, known as the delegator. The delegator object delegates the work to the delegate object, which performs the task and returns the result to the delegator.

Let’s use a real-life example to understand delegation in Kotlin. Consider a scenario where you have a restaurant with a customer, a waiter, and a chef. The customer wants to order a meal, and the waiter is responsible for taking the order and delivering it to the chef. The chef prepares the meal and hands it back to the waiter, who serves it to the customer.

In this example, the customer is the delegator, and the waiter is the delegate. The customer delegates the task of taking the order and delivering it to the waiter. The waiter performs these tasks on behalf of the customer and then delegates the task of preparing the meal to the chef. Finally, the waiter serves the meal back to the customer.

Let’s take one more example, consider a Car class that needs to perform some operations related to engine management. Instead of implementing those operations directly in the Car class, we can delegate them to an Engine object. This way, the Car class can focus on its core functionality, while the Engine object handles engine-related tasks.

Delegation provides benefits such as modularity, maintainability, and flexibility in designing software systems.

Overview of the Delegation Pattern

The delegation pattern is a design pattern where an object delegates some or all of its responsibilities to another object. Instead of inheriting behavior, an object maintains a reference to another object and forwards method calls to it. This promotes composition over inheritance and provides greater flexibility in reusing and combining behaviors from different objects.

In Kotlin, the delegation pattern is built into the language, making it easy and convenient to implement. With the by keyword, Kotlin allows a class to implement an interface by delegating all of its public members to a specified object. Let’s dive into the details and see how it works.

Basic Usage of Delegation in Kotlin

To understand the basic usage of delegation in Kotlin, let’s consider a simple example. Assume we have an interface called Base with a single function print()

interface Base {
    fun print()
}

Next, we define a class BaseImpl that implements the Base interface. It has a constructor parameter x of type Int and provides an implementation for the print() function.

class BaseImpl(val x: Int) : Base {
    override fun print() {
        println(x)
    }
}

Now, we want to create a class called Derived that also implements the Base interface. Instead of implementing the print() function directly, we can delegate it to an instance of the Base interface. We achieve this by using the by keyword followed by the object reference in the class declaration.

class Derived(b: Base) : Base by b

In this example, the by clause in the class declaration indicates that b will be stored internally in objects of Derived, and the compiler will generate all the methods of Base that forward to b. This means that the print() function in Derived will be automatically delegated to the print() function of the b object.