Functions in Kotlin are super important and they are one of the many vital aspects of the language. One special collection of standard functions is called scope functions which are part of the Kotlin library: let, run, also, apply and with.
There’s a big chance you came across those already but maybe you need some guidance on how to choose the right one and how to use them. With this article, I want to demonstrate the differences between all scope functions and discuss relevant use cases. Towards the end of the article there will be an example showing how to apply scope functions in order to structure Kotlin code in a more idiomatic way.

The Importance of Functions

In Kotlin, functions are as important as basic types such as integers or strings. Functions can exist on the same level as classes, may be assigned to variables and can also be passed to/returned from other functions. Kotlin makes functions “first-class citizens” of the language, which Wikipedia describes as follows:

A first-class citizen […] is an entity which supports all the operations generally available to other entities. These operations typically include being passed as an argument, returned from a function, modified, and assigned to a variable.

As already said, functions are as powerful and significant as any other type, e.g. Int. In addition to that, functions may appear as “higher-order functions”, which in turn is described as the following on Wikipedia:

In mathematics and computer science, a higher-order function (also functional, functional form or functor) is a function that does at least one of the following:
– takes one or more functions as arguments (i.e., procedural parameters),
– returns a function as its result.

Scope functions do also act as higher-order functions that take other functions as their argument. Before diving into this any further, let’s observe a simple example of higher-order functions.

Higher-Order Function in Action

A simple higher-order function that’s commonly known in Kotlin is called repeat and it’s defined in the standard library:

As shown, repeat takes two arguments: An ordinary integer times and a function of type (Int) -> Unit. According to the previously depicted definition, repeat is a higher-order function since it “takes one or more functions as arguments”. In its implementation, the function simply invokes action as often as times indicates. Let’s see how repeat can be used:

Note that if a function takes another function as the last parameter, the lambda expression argument can be passed outside the parenthesized argument list.

In the shown snippet, a regular lambda, which only prints the current repetition to the console, is passed to repeat. That’s how higher-order function calls look like.

Function Literal with Receiver

Kotlin promotes yet another very important concept that makes functions even more powerful. If you’ve ever seen internal domain specific languages (DSL) in action, you might have wondered how they are implemented. The most relevant concept to understand is called function literal with receiver (also lambda with receiver). As this feature is also vital for scope functions, it will be discussed in the following part.

Function literals with receiver are often used in combination with higher-order functions. As shown earlier, functions can be made parameters of other functions, which happens by defining parameters with the function type syntax (In) -> Out. Now imagine that these function types can even be boosted by adding a receiver: Receiver.(In) -> Out. Such types are called function literal with receiver and are best understood if visualized as “temporary extension functions”. Take the following example:

The function createString can be considered a higher-order function as it takes another function block as its argument. This argument is defined as a function literal with receiver type. Now, let’s think of it as an extension function defined for StringBuilder that will be passed to the createString function. Clients will pass in arbitrary functions with the signature () -> Unit, which will be callable on instances of StringBuilder. That’s also shown in the implementation: An instance of StringBuilder is created and block gets invoked on it. Eventually, the method transforms StringBuilderto an ordinary String and returns it to the caller.

How can you create and pass function literals with receiver to other functions?

Since the receiver is defined as StringBuilder, a client will be able to pass lambdas to createString that make use of that receiver. The receiver is exposed as this inside the lambda, which means that clients can access visible members (properties, functions etc.) without additional qualifiers:

The example shows that append, a function defined for the receiver StringBuilder, is being invoked without any qualifiers (e.g. it). The same is possible in the definition of extension functions, which is why I used it as an analogy earlier. The client defines a temporary extension function which gets invoked on the corresponding receiver within createString afterward. For another description of the concept, please consult the associated documentation. I also tried to answer a related StackOverflow question a while ago.

Scope Functions

Scope functions make use of the concepts described above. They are defined as higher-order functions, i.e. they take another function as their argument. These arguments may even appear as function literals with receiver in certain cases. Scope functions take an arbitrary object, the context object, and bring it into another scope. In that scope, the context object is either accessible as it (or custom name) or this, depending on the type of function. In the following, the functions let, run, also, apply and with will be introduced and explained.

[let]

Documentation: https://kotlinlang.org/api/latest/jvm/stdlib/kotlin/let.html

One of the most famous scope functions islet. It’s inspired by functional programming languages like Haskell and is used quite often in the Kotlin language, too. Let’s inspect its signature:

• Defined as an extension on T, the receiver/context object
• Generic type R defines the function’s return value
• Result R of block will be the result of let itself, i.e. it can be an arbitrary value
• block argument with regular function type (T) -> R
• Receiver T is passed as argument to block

Use Cases

a. Idiomatic replacement for if (object != null) blocks

As you can read in the Kotlin Idioms section, let is supposed to be used to execute blocks if a certain object is not null.

The nullable text variable is brought into a new scope by let if it isn’t null. Its value then gets mapped to its length. Otherwise, the null value is mapped to a default length 0 with the help of the Elvis operator. As you can see, the context object text gets exposed as it inside let, which is the default implicit name for single parameters of a lambda.

b. Map nullable value if not null

The let function is also often used for transformations, especially in combination with, again, nullable types. This approach as well is defined as an idiom.

c. Confine scope of variable/computation

If a certain variable or computation is supposed to be available only in a confined scope and should not pollute the outer scope, let is useful:

The string "stringConfinedToLetScope" is made the context object of let, which uses the value for a simple transformation that is returned as the result of let. The outer scope only uses the transformed value and does not access the temporarily needed string. There’s no variable polluting the outer scope due to confining it to the relevant scope.

[run]

Documentation: https://kotlinlang.org/api/latest/jvm/stdlib/kotlin/run.html

As an alternative to let, the run function makes use of a function literal with receiver as used for the block parameter. Let’s inspect its signature:

• Defined as an extension on T, the receiver/context object
• Generic type R defines the function’s return value
• Result R of block will be the result of run itself, i.e. it can be an arbitrary value
• block argument defined as function literal with receiver T.() -> R

The run function is like let except for how block is defined.

Use Cases

run can basically serve the same use cases as let, whereas the receiver T is exposed as this inside the lambda argument:

a. Idiomatic replacement for if (object != null) blocks

b. Transformation

It’s also good to use run for transformations. The following shows an example that is even more readable than with let since it accesses the context object’s functions without qualifiers:

[also]

Documentation: https://kotlinlang.org/api/latest/jvm/stdlib/kotlin/also.html

The also function is the scope function that got lastly added to the Kotlin language, which happened in version 1.1. Let’s inspect its signature:

• Defined as an extension on T, the receiver/context object
• Returns the receiver object T
• block argument with regular function type (T) -> Unit
• Receiver T is passed as argument to block

also looks like let, but it returns the receiver T as its result.

Use Cases

a. Receiver not used inside the block

It might be desired to do some tasks related to the context object but without actually using it inside the lambda argument. An example can be logging. As described in the official Kotlin coding conventions, using also is the recommended way to solve scenarios like the one shown next:

In this case, the code almost reads like a normal sentence: Assign something to the variable and also log to the console.

b. Initializing an object

Another very common scenario that can be solved with also is the initialization of objects. As opposed to the two previously introduced scope functions, let and run, also returns the receiver object after the block execution. This fact can be very handy:

As shown, a Bar instance is created and also is used to directly initialize one of the instance’s properties. Since also returns the receiver object itself, the expression can directly be assigned to a variable of type Bar.

c. Assignment of calculated values to fields

The fact that also returns the receiver object after its execution can also be useful to assign calculated values to fields, as shown here:

A value gets calculated and assigned to a field with the help of also. Since also returns that calculated value, it can even be made the direct inline result of the surrounding function.

[apply]

Documentation: https://kotlinlang.org/api/latest/jvm/stdlib/kotlin/apply.html

The apply function is another scope function that was added because the community asked for it. Its main use case is the initialization of objects, similar to what also does. The difference will be shown next. Let’s inspect its signature first:

• Defined as an extension on T, the receiver/context object
• Returns the receiver object T
• block argument defined as function literal with receiver T.() -> R

The relation between apply and also is the same as between let and run: Regular lambda vs. Function literal with receiver parameter

Relation (apply,also) == Relation (run,let)

Use Cases

a. Initializing an object

The ultimate use case for apply is object initialization. The community actually asked for this function in relatively late stage of the language. You can find the corresponding feature request here.

Although also was already shown as a tool for solving these scenarios, apply has a big advantage: There’s no need to use it as a qualifier since the context object, the Bar instance in this case, is exposed as this. The difference got answered in this StackOverflow post.

b. Builder-style usage of methods that return Unit

As described in the Kotlin Idioms section, apply can be used for wrapping methods that would normally result in Unit responses.

In the example, apply is used to wrap simple property assignments that would usually simply result in Unit. Since the class wants to expose a builder-style API to the client, this approach is very useful as the setter-like methods return the surrounding object itself.

[with]

Documentation: https://kotlinlang.org/api/latest/jvm/stdlib/kotlin/with.html

The with function is the last scope function that we want to look at. It’s a very common feature in many older languages like Visual Basic and Delphi.
It varies from the other four functions in that it is not defined as an extension function. Let’s inspect its signature:

• Defined as an independent function that takes a receiver/context object T as its first argument
• Result R of block will be the result of with itself, i.e. it can be an arbitrary value
• block argument defined as function literal with receiver T.() -> R

This function aligns with let and run in regards to its return value R. It’s often said to be similar to apply; the difference got described here. Another simple description of with can be found here (both StackOverflow).

Use Cases

a. Working with an object in a confined scope

Also defined as an idiom, with is supposed to be used when an object is only needed in a certain confined scope.

The StringBuilder passed to with is only acting as an intermediate instance that helps in creating the more relevant String that gets created in with. It’s obvious that with is utilized for wrapping the calls to StringBuilder without exposing the instance itself to the outer scope.

b. Using member extensions of a class

Extension functions are usually defined on package level so that they can be imported and accessed from anywhere else with ease. It’s also possible to define these on class or object level, which is then called a “member extension function”. These kinds of extension functions can be used inside that class itself, but not from outside. To make those accessible from anywhere outside the enclosing class, that class has to be brought “into scope”. The with function is very useful here:

The object Foo defines a member extension function random(), which can be used only in the scope of that object. With the help of with, this can be achieved easily. Note that this strategy is especially recommendable if particular extension functions are to be grouped meaningfully.

Comparison and Overview

After the five different scope functions have been discussed, it’s necessary to see them all next to each other:

The scope functions also and apply both return the receiver object after their execution. In apply, the block parameter is defined as a function literal with receiver and T gets exposed as this, whereas in also, it’s a regular function type and T gets exposed as it.

The scope functions let and run on the other hand both return an arbitrary result R, i.e. the result of the block itself. Again, run works with a function literal with receiver, whereas let uses the simple function type.

Last but not least, with is kind of a misfit amongst the scope functions since it’s not defined as an extension on T. It defines two parameters, one of which represents the receiver object of this scope function. Same as apply and run, with works with function literal with receiver.

IDE Support

As of version 1.2.30, the IntelliJ IDEA Kotlin plugin offers intentions that can convert between let and run and also between also and apply calls. Read more about it here.

Example: Requesting a REST API

In this section, I’m going to show an example that applies the previously discussed scope functions on a pretty basic use case: Calling an HTTP REST endpoint. The goal is to provide functionality for requesting information about contributors of the jetbrains/kotlin GitHub project. To do so, we define the appropriate GitHub endpoint and a simplified representation of a Contributor that is annotated for Jackson:

The following shows the code that provides the desired functionality in its initial form:

This snippet shows a singleton object GitHubApiCaller with an OkHttpClient (OkHttp), a Jackson mapper and a simple Map that’s used for caching results. The implementation consists of following steps:

• When the result is already cached, return it immediately and skip the rest
• Create a request object using the ENDPOINT
• Get the response by executing the request on the client
• Extract the JSON data from the response object (Error handling omitted)
• De-serialize the JSON to an Array
• Filter for the contributor that is searched for
• Cache the result and return it to the client

In my opinion, this code is already quite straightforward. Nevertheless, it can be taken as a good basis for a little refactoring.

Reviewing the Code

Let’s now try to find some appropriate use cases for scope functions in the previously shown function.

Refactoring №1

The first thing that we can improve is the if block in the very beginning:

As shown earlier, the let function is normally used for resolving these kinds of if blocks. Applied to the concrete example, we get the following:

The problem here is that let is defined with a generic return type R so that the it needs to be written at the end in order to make it the return value of the expression. Another obvious insufficiency is the missing else statement. The first problem can be addressed pretty easily. We just need to use a scope function that returns its receiver, i.e. the cached result, directly from the block. Additionally, it should still expose the receiver as it, which makes also the best suitable candidate:

The Elvis operator, shown before, is very often used for handling the else case, i.e. when the receiver is null. To make the code more readable, a private function requestContributor now handles the cache miss.

That’s it, the if block was replaced with an easy also invocation. A more idiomatic solution.

Refactoring №2

The next portion that is worth reconsidering contains an unnecessary local variable that represents the request object:

It’s literally only used for getting a response object from the client and could therefore simply be inlined. Alternatively, the shown actions can be thought of as a basic transformation, which we learned to express with the let function:

The request has been made the context object of let and directly gets executed in a straightforward transformation. It makes the local request variable obsolete without affecting readability negatively.

Refactoring №3

The following snippet points at another if (obj != null) block, which in this case can actually be solved with let:

Again, the Elvis operator handles the null scenario very nicely.

Refactoring №4

Moving on to the next two statements of the code, we observe that the responseAsString variable is being logged and finally used for the Jackson de-serialization. Let’s group them together:

Refactoring №5

After the first few refactorings, the situation looks as follows: We have a response, a responseAsString and a contributors variable and still need to filter the Contributors for the desired entry. Basically, the whole requesting and response handling is not relevant for the last step of filtering and caching. We can smoothly group these calls and confine them to their own scope. Since these actions happen with the help of the OkHttpClient, it makes sense to make the client the context object of that scope:

There isn’t any new code here, the previous edits have simply be wrapped in a call of with and are therefore not visible to the surrounding scope (function requestContributors) anymore. It made sense to use with in this case as it exposes client as this and the newCall invocation can therefore omit its qualifier. As described earlier, with can have an arbitrary result R. In this case, the last statement inside the lambda, the result of the last let call, becomes that R.

Refactoring №6

Now a single variable contributors is available in the outer scope and we can apply the filtering:

The previous version of the above code consisted of four independent statements that are now grouped in a simple also call with the filtered Contributor as its receiver. That receiver is put in the cache and also logged for debugging purposes. Of course, since also returns its receiver directly, the whole statement can be made the return of the function.

The entire function looks like this:

In my opinion, the code looks very well structured and still readable. Yet, I don’t want to encourage you all to apply scope functions in EVERY situation . It’s very important to know that this set of functions is so powerful that they could even be used to chain an unlimited amount of expressions and make them a single expression. You don’t want to do that because it messes up the code very quickly. Try to find a balance here and don’t apply scope functions everywhere.

Conclusion

In this article, I discussed the powerful set of scope functions of the Kotlin standard library. Many situations can be solved in a very idiomatic way with the help of these functions and it’s vital to have a rough idea of the differences between them. Try to memorize that there are scope functions that can return arbitrary values (let, run, with) and those that return the receiver itself (apply, also). Then there are functions that expose their receiver as it (let, also) and others that expose their receiver as this (run, apply, with). The concluding example demonstrated how easily scope functions may be used for refactoring appropriate code sections according to the earlier learned concepts. You shouldn’t get the impression that every single opportunity should actually be embraced; it’s still necessary to reason about the application of scope functions. Also, you shouldn’t try to use each and every of the shown functions at any price since most of them can be used quite interchangeably. Try to find your own favorites. 🙂

This article was originally published on proandroiddev.com on September 15, 2022