Typealias — What It Is, Syntax and Usage in Kotlin

What is typealias?

Typealias (type alias) is a declaration that introduces an alternative name for an existing type. Syntax: typealias NewName = ExistingType. After declaration, NewName can be used wherever ExistingType is expected — the compiler treats them as the same type. At the bytecode level, typealias leaves no traces: all alias information is erased at compile time.

The main purpose of typealias is improving code readability. Instead of a verbose signature fun process(callback: (Result) -> Unit), you can write typealias Callback = (Result) -> Unit and use Callback as the parameter type. This is especially useful when the same functional type is repeated in several places in the code: the alias serves as a single point of definition and documents the type's purpose.

Typealias does not create a new type — it is just a synonym. Variables of type Callback and (Result) -> Unit are fully interchangeable. The compiler will not produce an error if a lambda is passed directly to a function expecting Callback. This distinguishes typealias from inline class (value class), which creates a new wrapper type with compile-time checking. Typealias is renaming, not wrapping.

Typealias for Functional Types

The most common use case for typealias in Kotlin is functional types. Long signatures like (Int, String) -> Boolean or (List) -> Result make code hard to read. Typealias turns them into short meaningful names that document the function's purpose: typealias Validator = (String) -> Boolean specifies that this is a string validator.

// Without typealias
fun findUsers(
    filter: (List<User>) -> List<User>
): List<User>

// With typealias
typealias UserFilter = (List<User>) -> List<User>

fun findUsers(filter: UserFilter): List<User>

// Usage in class
typealias OnClickListener = (View) -> Unit

class Button {
    var onClick: OnClickListener = {}
}

In the example, the typealias UserFilter hides the complex functional type (List) -> List behind a short name. The findUsers signature becomes readable: "accepts UserFilter, returns List". The typealias OnClickListener makes the code resemble an interface declaration but without the overhead of creating a separate interface or abstract class. Meanwhile, lambdas and anonymous functions continue to work as usual — typealias requires no changes in the calling code.

Typealias with Generics

Typealias supports generic parameters, making it even more flexible. You can define typealias Mapper = (T) -> R and use it with any types. The compiler substitutes specific types for parameters with each use of the alias, preserving full type safety.

// Generic typealias
typealias Mapper<T, R> = (T) -> R
typealias Provider<T> = () -> T
typealias ListTransformer<T> = (List<T>) -> List<T>

fun processNumbers(mapper: Mapper<Int, String>) {
    // mapper type is (Int) -> String
}

fun main() {
    val config: Provider<String> = { "default config" }
    val reverse: ListTransformer<Int> = { it.reversed() }
}

In the listing, Mapper is a generic alias for any transformation from T to R. Provider is a value supplier (a factory without arguments). ListTransformer is a list transformation function. When calling processNumbers(mapper: Mapper), the compiler expands the alias to (Int) -> String. Generics make typealias a universal tool suitable for any context without duplicating declarations.

Typealias for Nested and Long Names

Nested classes and long parameterized types are another area where typealias significantly simplifies code. If a class is deep in a nesting hierarchy (Outer.Inner.Nested), referencing it by its full name clutters the code. Typealias shortens such access and makes it more readable. This is especially relevant for classes from third-party libraries with long names.

// Alias for nested class
class NetworkResponse {
    class Error(val code: Int, val message: String)
}
typealias NetworkError = NetworkResponse.Error

// Alias for long library type
typealias UserId = Long
typealias JsonMap = Map<String, Any?>

fun process(error: NetworkError) {
    println("${error.code}: ${error.message}")
}

fun parseJson(data: JsonMap): UserId {
    return data["id"] as? Long ?: 0L
}

In the example, NetworkError is an alias for the nested class NetworkResponse.Error. By importing the typealias, you can use NetworkError as a regular type without revealing the nesting hierarchy. JsonMap documents that the map represents a JSON object. UserId clarifies the purpose of Long in a specific context — the reader immediately understands that this is a user identifier, not an arbitrary number. However, typealias does not prevent passing a plain Long where UserId is expected — for that, a value class is needed.

Typealias vs Inline Class: Differences

Typealias and inline class (value class) solve different problems, although both introduce a new name for a type. Typealias is just a synonym: a variable of type UserId = Long accepts any Long without checking. Inline class wraps a value into a new type that is checked at compile time: passing a plain Long where an inline class UserId is expected is impossible without explicit conversion.

The table shows the difference between the two mechanisms. Typealias is suitable for concise names and code documentation when strict typing is not required. Inline class via the value class keyword (formerly inline class) is needed when it is important to distinguish semantically different values of the same primitive type. For example, UserId and OrderId are both Long, but passing one where the other is expected is a logical error that value class prevents at compile time.