Kotlin language specification

Declarations in Kotlin are used to introduce entities (values, types, etc.); most declarations are named, i.e. they also assign an identifier to their own entity, however, some declarations may be anonymous.

Every declaration is accessible in a particular scope, which is dependent both on where the declaration is located and on the declaration itself. Every named declaration introduces a binding for this name in the scope it is declared in. For most of the declarations, this scope is the declaration scope introduced by the parent declaration, e.g. the declaration this declaration is syntactically nested in. See scoping section for details.

Classifier declarations introduce new types to the program, of the forms described here. There are three kinds of classifier declarations:

A simple class declaration consists of the following parts.

and creates a simple classifier type $c : S_1, \ldots, S_s$ .

Supertype specifiers are used to create inheritance relation between the declared type and the specified supertype. You can use classes and interfaces as supertypes, but not objects or inner classes.

It is allowed to inherit from a single class only, i.e., multiple class inheritance is not supported. Multiple interface inheritance is allowed.

Instance initialization block describes a block of code which should be executed during object creation.

Property and function declarations in the class body introduce their respective entities in this class’ scope, meaning they are available only on an entity of the corresponding class.

Companion object declaration companion object CO { ... } for class C introduces an object, which is available under this class’ name or under the path C.CO. Companion object name may be omitted, in which case it is considered to be equal to Companion.

Nested classifier declarations introduce new classifiers, available under this class’ name. Further details are available here.

A parameterized class declaration, in addition to what constitutes a simple class declaration, also has a type parameter list $T_1, \ldots, T_m$ and extends the rules for a simple class declaration w.r.t. this type parameter list. Further details are described here.

There are two types of class constructors in Kotlin: primary and secondary.

A primary constructor is a concise way of describing class properties together with constructor parameters, and has the following form

$\operatorname{\mathit{ptor}}: (p_1, \ldots, p_n)$

where each of $p_i$ may be one of the following:

Property constructor parameters, together with being regular constructor parameters, also declare class properties of the same name and type.

One can consider primary constructor parameters to have the following syntactic expansion.

When accessing property constructor parameters inside the class body, one works with their corresponding properties; however, when accessing them in the supertype specifier list (e.g., as an argument to a superclass constructor invocation), we see them as actual parameters, which cannot be changed.

If a class declaration has a primary constructor and also includes a class supertype specifier, that specifier must represent a valid invocation of the supertype constructor.

A secondary constructor describes an alternative way of creating a class instance and has only regular constructor parameters.

If a class has a primary constructor, any secondary constructor must delegate to either the primary constructor or to another secondary constructor via this(...).

If a class does not have a primary constructor, its secondary constructors must delegate to either the superclass constructor via super(...) (if the superclass is present in the supertype specifier list) or to another secondary constructor via this(...). If the only superclass is kotlin.Any, delegation is optional.

In all cases, it is forbidden if two or more secondary constructors form a delegation loop.

Class constructors (both primary and secondary) may have variable-argument parameters and default parameter values, just as regular functions. Please refer to the function declaration reference for details.

If a class does not have neither primary, nor secondary constructors, it is assumed to implicitly have a default parameterless primary constructor. This also means that, if a class declaration includes a class supertype specifier, that specifier must represent a valid invocation of the supertype constructor.

Similar to function declarations, a constructor introduces two scopes: a constructor parameter scope and a constructor body scope, see function declaration section for details. The constructor parameter scope is upward-linked to the static classifier declaration scope of its classifier. In addition to this, primary constructor parameter scope is downward-linked to the classifier initialization scope. There is also no primary constructor body scope as primary constructor has no body.

If a classifier declaration $\operatorname{\text{ND}}$ is nested in another classifier declaration $\operatorname{\text{PD}}$ , it creates a nested classifier type — a classifier type available under the path $\operatorname{\text{PD}}.\operatorname{\text{ND}}$ . In all other aspects, nested classifiers are equivalent to regular ones.

Inner classes are a special kind of nested classifiers, which introduce types of objects associated (linked) with other (parent) objects. An inner class declaration $\operatorname{\text{ID}}$ nested in another classifier declaration $\operatorname{\text{PD}}$ may reference an object of type $\operatorname{\text{ID}}$ associated with it.

This association happens when instantiating an object of type $\operatorname{\text{ID}}$ , as its constructor may be invoked only when a receiver of type $\operatorname{\text{PD}}$ is available, and this receiver becomes associated with the new instantiated object of type $\operatorname{\text{ID}}$ .

Inner classes cannot be declared in interface declarations, as interfaces cannot be instantiated.

Inner classes cannot be declared in a statement scope, as such scope does not have an object to associate the inner class with.

Inner classes cannot be declared in object declarations, as object declarations also create a single named value of their type, which makes additional association unnecessary.

In a classifier (an object or a class) declaration $C$ , any supertype $I$ inheritance may be delegated to an arbitrary value $v$ if:

The inheritance delegation uses a syntax similar to property delegation using the by keyword, but is specified in the classifier declaration header and is a very different concept. If inherited using delegation, each method $M$ of $I$ (whether they have a default implementation or not) is delegated to the corresponding method of $v$ as if it was overridden in $C$ with all the parameter values directly passed to the corresponding method in $v$ , unless the body of $C$ itself has a suitable override of $M$ (see the method overriding section).

The particular means on how $v$ is stored inside the classifier object is platform-defined.

Due to the initialization order of a classifier object, the expression used to construct $v$ can not access any of the classifier object properties or methods excluding the parameters of the primary constructor.

A class declaration can be marked abstract. Such classes cannot be instantiated directly; they are used as superclasses for other classes or objects.

Abstract classes may contain one or more abstract members: members without implementation, which should be implemented in a subtype of this abstract class.

A data class $\operatorname{\mathit{dataClass}}$ is a special kind of class, which represents a product type constructed from a number of data properties $(\operatorname{\mathit{dp}}_1, \ldots, \operatorname{\mathit{dp}}_m)$ , described in its primary constructor. Non-property constructor parameters are not allowed in the primary constructor of a data class. As such, data classes allow Kotlin to reduce the boilerplate and generate a number of additional data-relevant functions.

All these functions consider only data properties $\{\operatorname{\mathit{dp}}_i\}$ ; e.g., your data class may include regular property declarations in its body, however, they will not be considered in the equals() implementation or have a componentN() generated for them.

There are several rules as to how these generated functions may be explicified or inherited.

The declarations of equals, hashCode and toString may be explicified similarly to how overriding works in normal classes. If a correct explicit implementation is available, no function is generated. Other functions (copy, componentN) cannot be explicified.

The declarations of equals, hashCode and toString may be inherited from the base class, if it provides a final version with a matching signature. If a correct inherited implementation is available, no function is generated. Other functions (copy, componentN) cannot be inherited.

In addition, for every generated function, if any of the base types provide an open function with a matching signature, it is automatically overridden by the generated function as if it was generated with an override modifier.

Data classes have the following restrictions:

A data object $\operatorname{\mathit{dataObject}}$ is a special kind of object, which extends the data class abstraction (product type of one or more data properties) to a case of unit type: product type of zero data properties.

Similarly to data classes, there are a number of functions with predefined behaviour generated for data objects.

Unlike data classes, however, for data objects the only generated function which can be exemplified or inherited is toString(); equals() and hashCode() for a data object always work as specified above. This is to ensure data objects do not violate the unit type invariant of “being inhabited by only one value”, which would be possible if one were to provide a custom equals() implementation.

If either equals() or hashCode() function would be exemplified or inherited by a data object, it is a compile-time error.

Data objects have the same restrictions are regular objects.

Enum class $E$ is a special kind of class with the following properties:

Enum class body uses special kind of syntax (see grammar) to declare enum entries in addition to all other declarations inside the class body. Enum entries have their own bodies that may contain their own declarations, similar to object declarations.

Every enum entry of class E implicitly overrides members of kotlin.Enum<E> in the following way:

In addition to these, every enum class type E has the following static members declared implicitly:

Kotlin standard library also introduces a function to access all enum values for a specific enum class called kotlin.enumEntries<T>. Please refer to the standard library documentation for details.

For backwards compatibility, in addition to the entries property, every enum class type E has the following static member function declared implicitly.

Kotlin standard library also introduces another function to access all enum values for a specific enum class called kotlin.enumValues<T> (which is deprecated for subsequent removal). Please refer to the standard library documentation for details.

Annotations class is a special kind of class that is used to declare annotations. Annotation classes have the following properties:

The main use of annotation classes is when specifying code annotations for other entities. Additionally, annotation classes can be instantiated directly, for cases when you require working with an annotation instance directly. For example, this is needed for interoperability with some Java annotation APIs, as in Java you can implement an annotation interface and then instantiate it.

A class may be declared a value class by using inline or value modifier in its declaration. Value classes must adhere to the following limitations:

Value classes implicitly override equals and hashCode member functions of kotlin.Any by delegating them to their only data property. Unless toString is overridden by the value class definition, it is also implicitly overridden by delegating to the data property. In addition to these, an value class is allowed by the implementation to be inlined where applicable, so that its data property is operated on instead. This also means that the property may be boxed back to the value class by using its primary constructor at any time if the compiler decides it is the right thing to do.

Due to these restrictions, it is highly discouraged to use value classes with the reference equality operators.

Interfaces differ from classes in that they cannot be directly instantiated in the program, they are meant as a way of describing a contract which should be satisfied by the interface’s subtypes. In other aspects they are similar to classes, therefore we shall specify their declarations by specifying their differences from class declarations.

A functional interface is an interface with a single abstract function and no other abstract properties or functions.

A function interface declaration is marked as fun interface. It has the following additional restrictions compared to regular interface declarations.

A functional interface has an associated function type, which is the same as the function type of its single abstract member function.

If one needs an object of a functional interface type, they can use the regular ways of implementing an interface, either via an anonymous object declaration or as a complete class. However, as functional interface essentially represents a single function, Kotlin supports the following additional ways of providing a functional interface implementation from function values (expressions with function type).

Object declarations are similar to class declaration in that they introduce a new classifier type, but, unlike class or interface declarations, they also introduce a value of this type in the same declaration. No other values of this type may be declared, making object a single existing value of its type.

Similarly to interfaces, we shall specify object declarations by highlighting their differences from class declarations.

A class (but not an interface or an object) may be declared locally inside a statement scope (namely, inside a function). Such declarations are similar to object literals in that they may capture values available in the scope they are declared in:

Enum classes and annotation classes cannot be declared locally.

When creating a class or object instance via one of its constructors $ctor$ , it is initialized in a particular order, which we describe here.

A primary $pctor$ or secondary constructor $ctor$ has a corresponding superclass constructor $sctor$ defined as follows.

When a classifier type is initialized using a particular secondary constructor $ctor$ delegated to primary constructor $pctor$ which, in turn, is delegated to the corresponding superclass constructor $sctor$ , the following happens, in this initialization order:

The initialization order stays the same if any of the entities involved are omitted, in which case the corresponding step is also omitted (e.g., if the object is created using the primary constructor, the body of the secondary one is not invoked).

If any step in the initialization order creates a loop, it results in unspecified behaviour.

If any of the properties are accessed before they are initialized w.r.t initialization order (e.g., if a method called in an initialization block accesses a property declared after the initialization block), the value of the property is unspecified. It stays unspecified even after the “proper” initialization is performed.

Every classifier declaration introduces two declarations scope syntactically bound by the classifier body, if any: the static classifier body scope and the actual classifier body scope Every function, property or inner classifier declaration contained within the classifier body are declared in the actual classifier body scope of this classifier. All non-primary constructors of the classifier, as well as any non-inner nested classifier, including the companion object declaration (if it exists) and enum entries (if this is an enum class), are declared in the static classifier body scope. Static classifier body scope is upwards-linked to the actual classifier body scope. For an object declaration, static classifier body scope and the actual classifier body scoped are one and the same.

In addition to this, objects and classes introduce a special object initialization scope, which is not syntactically delimited. The scopes of each initialization expression of every property in the class body, as well as the scopes of each initialization block, is upward-linked to the object initialization scope, which itself is upward-linked to the actual classifier body scope.

If a classifier declares a primary constructor, the parameters of this constructor are bound in the special primary constructor parameter scope, which is downward-linked to the initialization scope and upward-linked to the scope the classifier is declared in. The interface delegation expressions (if any) are resolved in the primary constructor parameter scope if it exists and in the scope the classifier is declared in otherwise.

Function declarations assign names to functions — blocks of code which may be called by passing them a number of arguments. Functions have special function types which are covered in more detail here.

A simple function declaration consists of four main parts:

and has a function type $f : (p_1: P_1, \ldots, p_n: P_n) \rightarrow R$ .

Parameter list $(p_1: P_1 [= v_1], \ldots, p_n: P_n [= v_n])$ describes function parameters, i.e. inputs needed to execute the declared function. Each parameter $p_i: P_i = v_i$ introduces $p_i$ as a name of value with type $P_i$ available inside function body $b$ ; therefore, parameters are final and cannot be changed inside the function. A function may have zero or more parameters.

A parameter may include a default value $v_i$ , which is used if the corresponding argument is not specified in function invocation; $v_i$ must be an expression which evaluates to type $V <: P_i$ .

Return type $R$ , if omitted, is calculated as follows.

In other cases return type $R$ cannot be omitted and must be specified explicitly.

Function body $b$ is optional; if it is omitted, a function declaration creates an abstract function, which does not have an implementation. This is allowed only inside an abstract class or an interface. If a function body $b$ is present, it should evaluate to type $B$ which should satisfy $B <: R$ .

A parameterized function declaration consists of five main parts.

and extends the rules for a simple function declaration w.r.t. type parameter list. Further details are described here.

In some cases we need to establish whether one function declaration matches another, e.g., for checking overridability. To do that, we compare function signatures, which consist of the following.

Two function signatures $A$ and $B$ are considered matching, if the following is true.

Kotlin supports named parameters out-of-the-box, meaning one can bind an argument to a parameter in function invocation not by its position, but by its name, which is equal to the argument name.

All the names of named parameters are resolved at compile-time, meaning that performing a call with a parameter name not used at declaration-site is a compile-time error.

If one wants to mix named and positional arguments, the argument list must conform to the following form: $PoN_1, \ldots, PoN_M, N_1, \ldots, N_Q$ , where $PoN_i$ is an i-th argument in either positional or named form, $N_j$ is a named argument irregardless of its position.

If one needs to provide a named argument to a variable length parameter, it can be achieved via either regular named argument arg = arr or a spread operator expression form arg = *arr. In both cases type of arr must be a subtype of $\operatorname{\text{ATS}}(\operatorname{\texttt{kotlin.Array}}(\operatorname{\texttt{out\,}}T))$ for a variable length parameter of type $T$ .

Kotlin also supports default parameters — parameters which have a default value used in function invocation, if the corresponding argument is missing. Note that default parameters cannot be used to provide a value for positional argument in the middle of the positional argument list; allowing this would create an ambiguity of which argument for position $i$ is the correct one: explicit one provided by the developer or implicit one from the default value.

In summary, argument list should have the following form:

Missing arguments are bound to their default values, if they exist.

The evaluation order of argument list is described in Function calls and property access section of this specification.

One of the parameters may be designated as being variable length (aka vararg). A parameter list $(p_1, \ldots, \text{vararg }p_i: P_i = v_i, \ldots, p_n)$ means a function may be called with any number of arguments in the i-th position. These arguments are represented inside function body $b$ as a value $p_i$ of type, which is the result of array type specialization of type $\operatorname{\texttt{kotlin.Array}}(\operatorname{\texttt{out\,}}P_i)$ .

If a variable length parameter is not last in the parameter list, all subsequent arguments in the function invocation should be specified as named arguments.

If a variable length parameter has a default value, it should be an expression which evaluates to a value of type, which is the result of array type specialization of type $\operatorname{\texttt{kotlin.Array}}(\operatorname{\texttt{out\,}}P_i)$ .

A value of type $Q <: \operatorname{\text{ATS}}(\operatorname{\texttt{kotlin.Array}}(\operatorname{\texttt{out\,}}P_i))$ may be unpacked to a variable length parameter in function invocation using spread operator; in this case array elements are considered to be separate arguments in the variable length parameter position.

A function invocation may include several spread operator expressions corresponding to the vararg parameter. These may also be freely mixed with non-spread-expression arguments.

An extension function declaration is similar to a standard function declaration, but introduces an additional special function parameter, the receiver parameter. This parameter is designated by specifying the receiver type (the type before . in function name), which becomes the type of this receiver parameter. This parameter is not named and must always be supplied (either explicitly or implicitly), e.g. it cannot be a variable-argument parameter, have a default value, etc.

Calling such a function is special because the receiver parameter is not supplied as an argument of the call, but as the receiver of the call, be it implicit or explicit. This parameter is available inside the scope of the function as the implicit receiver or this-expression, while nested scopes may introduce additional receivers that take precedence over this one. See the receiver section for details. This receiver is also available (as usual) in nested scope using labeled this syntax using the name of the declared function as the label.

For more information on how a particular receiver for each call is chosen, please refer to the overloading section.

For all other purposes, extension functions are not different from non-extension functions.

Examples:

A function may be declared inline using a special inline modifier. This allows the compiler to inline the function at call-site, replacing the call with the body of the function with arguments mapped to corresponding parameters. It is unspecified whether inlining will actually be performed, however.

Declaring a function inline has two additional effects:

Inlined parameters are not allowed to escape the scope of the function body, meaning that they cannot be stored in variables, returned from the function or captured by other values. They may only be called inside the function body or passed to other functions as inline arguments.

Crossinline parameters may not be stored or returned from the function, but may be captured (for example, by object literals or other noinline lambda literals).

Noinline parameters may be treated as any other values. They may also be passed to other functions as noinline or crossinline arguments.

Particular platforms may introduce additional restrictions or guarantees for the inlining mechanism.

A function may be declared as an infix function by using a special infix modifier. An infix function can be called in an infix form, i.e., a foo b instead of a.foo(b).

To be a valid infix function, function $F$ must satisfy the following requirements.

A function may be declared locally inside a statement scope (namely, inside another function). Such declarations are similar to function literals in that they may capture values available in the scope they are declared in. Otherwise they are similar to regular function declarations.

A function may be declared tail-recursive by using a special tailrec modifier. A tail-recursive function that contains a recursive call to itself may be optimized to a non-recursive form by a particular platform in order to avoid problems of recursion such as a possibility of stack overflows possible on some platforms.

In order to be applicable for such an optimization, the function must adhere to tail recursive form: for all paths containing recursive calls the result of the recursive call must also be the result of the function. If a function declaration is marked with the tailrec modifier, but is not actually applicable for the optimization, it must produce a compile-time warning.

Every function declaration body introduces a function body scope, which is a statement scope containing everything declared inside the function body and is delimited by the function body itself.

In addition to this scope, function parameters exist in a special function parameter scope, which is upward-linked to the scope the function is declared in and downward-linked to the function body scope.

Kotlin uses properties to represent object-like entities, such as local variables, class fields or top-level values.

Property declarations may create read-only (val) or mutable (var) entities in their respective scope.

Properties may also have custom getter or setter — special functions which are used to read or write the property value. Getters and setters cannot be called directly, but rather define how the corresponding properties are evaluated when accessed.

A read-only property declaration val x: T = e introduces x as a name of the result of e.

A read-only property declaration may include a custom getter in the form of

or

in which case x is used as a synonym to the getter invocation. All of the right-hand value e, the type T in both positions, and the getter are optional, however, at least one of them must be specified. More so, if we cannot infer the resulting property type from the type of e or from the type of getter in expression form (2), the type T must be specified explicitly either as the property type, or as the getter return type. In case both e and T are specified, the type of e must be a subtype of T (see subtyping for more details).

The initializer expression e, if given, serves as the starting value for the property backing field (see getters and setters section for details) and is evaluated when the property is created. Properties that are not allowed to have backing fields (see getters and setters section for details) are also not allowed to have initializer expressions.

A mutable property declaration var x: T = e introduces x as a name of a mutable variable with type T and initial value equals to the result of e. The rules regarding the right-hand value e and the type T match those of a read-only property declaration.

A mutable property declaration may include a custom getter and/or custom setter in the form of

in which case x is used as a synonym to the getter invocation when read from and to the setter invocation when written to.

If a property declaration is local, it creates a local entity which follows most of the same rules as the ones for regular property declarations. However, local property declarations cannot have custom getters or setters.

Local property declarations also support destructuring declaration in the form of

which is a syntactic sugar for the following expansion

where componentN() should be a valid operator function available on the result of e. Some of the entries in the destructuring declaration may be replaced with an ignore marker _, which signifies that no variable is declared and no componentN() function is called.

As with regular property declaration, type specification is optional, in which case the type is inferred from the corresponding componentN() function. Destructuring declarations cannot use getters, setters or delegates and must be initialized in-place.

As mentioned before, a property declaration may include a custom getter and/or custom setter (together called accessors) in the form of

These functions have the following requirements

One can also omit the accessor body, in which case a default implementation is used (also known as default accessor).

Getters and setters allow one to customize how the property is accessed, and may need access to the property’s backing field, which is responsible for actually storing the property data. It is accessed via the special field property available inside accessor body, which follows these conventions

However, the backing field is created for a property only in the following cases

In all other cases a property has no backing field. Properties without backing fields are not allowed to have initializer expressions.

Read/write access to the property is replaced with getter/setter invocation respectively. Getters and setters allow for some modifiers available for function declarations (for example, they may be declared inline, see grammar for details).

Properties themselves may also be declared inline, meaning that both getter and setter of said property are inline. Additionally, inline properties are not allowed to have backing fields, i.e., they must have custom accessors which do not use the field property.

A delegated read-only property declaration val x: T by e introduces x as a name for the delegation result of property x to the entity e or to the delegatee of e provided by provideDelegate. For the former, one may consider these properties as regular properties with a special delegating getters:

is the same as

Here every access to such property (x in this case) becomes an overloadable form which is expanded into the following:

where

A delegated mutable property declaration var x: T by e introduces x as a name of a mutable entity with type T, access to which is delegated to the entity e or to the delegatee of e provided by provideDelegate. As before, one may view these properties as regular properties with special delegating getters and setters:

is the same as

Read access is handled the same way as for a delegated read-only property. Any write access to x (using, for example, an assignment operator x = y) becomes an overloadable form with the following expansion:

where

The type of a delegated property may be omitted at the declaration site, meaning that it may be inferred from the delegating function itself, as it is with regular getters and setters. If this type is omitted, it is inferred as if it was assigned the value of its expansion. If this inference fails, it is a compile-time error.

For both provided and standard delegates, the generated delegate value is placed in the same context as its corresponding property. This means that for a class member property it will be a synthetic member, for a local property it is a local value in the same scope as the property and for top-level (both extension and non-extension) properties it will be a top-level value. This affects this value’s lifetime in the same way normal value lifetime works.

An extension property declaration is similar to a standard property declaration, but, very much alike an extension function, introduces an additional parameter to the property called the receiver parameter. This is different from usual property declarations, that do not have any parameters. There are other differences from standard property declarations:

Aside from these differences, extension properties are similar to regular properties, but, when accessing such a property one always need to supply a receiver, implicit or explicit. Like for regular properties, the type of the receiver must be a subtype of the receiver parameter, and the value that is supplied as the receiver is bound to the receiver parameter. For more information on how a particular receiver for each access is chosen, please refer to the overloading section.

The receiver parameter can be accessed inside getter and setter scopes of the property as the implicit receiver or this. It may also be accessed inside nested scopes using labeled this syntax using the name of the property declared as the label. For delegated properties, the value passed into the operator functions getValue and setValue as the receiver is the value of the receiver parameter, rather than the value of the outer classifier. This is also true for local extension properties: while regular local properties are passed null as the first argument of these operator functions, local extension properties are passed the value of the receiver argument instead.

For all other purposes, extension properties are not different from non-extension properties.

All non-abstract properties must be definitely initialized before their first use. To guarantee this, Kotlin compiler uses a number of analyses which are described in more detail here.

A property may be declared constant, meaning that its value is known during compilation, by using the special const modifier. In order to be declared const, a property must meet the following requirements:

A mutable member property can be declared with a special lateinit modifier, effectively turning off the property initialization checks for it. Such a property is called late-initialized and may be used for values that are supposed to be initialized not during object construction, but during some other time (for example, a special initialization function). This means, among other things, that it is the responsibility of the programmer to guarantee that the property is initialized before its usage.

A property may be declared late-initialized if:

Every property getter and setter introduce the same function parameter scope and function body scope as a corresponding function would, see function declaration scopes for details. Getter and setter parameter scopes are upward-linked to the scope property is declared in. Property itself introduces a new binding in the scope it is declared in.

Initialization expressions and delegate expressions for properties, however, are special. If the property declaration resides in a classifier body scope, its initialization expression or delegate expression is resolved in the initialization scope of the same classifier. If the property declaration is local or top-level, its initialization expression or delegate expression is resolved in the scope the property is declared in.

Type alias introduces an alternative name for the specified type and supports both simple and parameterized types. If type alias is parameterized, its type parameters must be unbounded and cannot specify variance. Bounds and variance of these parameters is always defined to be the same as the corresponding parameters in the type being aliased, unless they are not referenced in the aliased type, in which case they are considered unbounded and invariant. Another restriction is that recursive type aliases are forbidden — the type alias name cannot be used in its own right-hand side.

At the moment, Kotlin supports only top-level type aliases. The scope where it is accessible is defined by its visibility modifiers.

Most declarations may be introduced as generic, introducing type parameters that must be explicitly specified or inferred when the corresponding declaration is used. For declarations that introduce new types this mechanism provides the means of introducing a parameterized type. Please refer to the corresponding section for details.

Type parameters may be used as types inside the scope introduced by the declaration. When such a declaration is used, the parameters are substituted by types available inside the scope the declaration is used in.

The following declarations are not allowed to have type parameters:

Type parameters are allowed to specify subtyping restrictions on them in the form T : U, meaning $T <: U$ where $T$ is a type parameter and $U$ is some other type available in the scope the declaration is declared in. These either are written directly at the parameter placement syntax or using a special where syntax. Any number of restrictions is allowed on a single type, however, for a given type parameter T, only one restriction T : U can have U to be another type parameter.

These restrictions are turned into corresponding type constraints when the type parameters are substituted with types and are employed during type inference and overload resolution of any usage of the corresponding declaration. See the corresponding sections for details.

Type parameters do not introduce runtime-available types unless declared reified. Only type parameters of inline functions can be declared reified.

The declaration-site variance of a particular type parameter for a classifier declaration is specified using special keywords in (for covariant parameters) and out (for contravariant parameters). If the variance is not specified, the parameter is implicitly declared invariant. See the type system section for details.

A type parameter is used in covariant position in the following cases:

A type parameter is used in contravariant position in the following cases:

A type parameter is used in an invariant position if it is used as an argument in another generic type and the corresponding parameter in that type is invariant.

A usage of a contravariant type parameter in a covariant or invariant position, as well as usage of a covariant type parameter in a contravariant or invariant position, results in variance conflict and a compiler error, unless the containing declaration is private to the type parameter owner (in which case its visibility is restricted, see the visibility section for details). This applies only to member declarations of the corresponding class, extensions are not subject to this limitation.

This restrictions may be lifted in particular cases by annotating the corresponding type parameter usage with a special built-in annotation kotlin.UnsafeVariance. By supplying this annotation the author of the code explicitly declares that safety features that variance checks provide are not needed in this particular declarations.