The KotlinDocumentation Index
Fetch the complete documentation index at: https://docs.syntblaze.com/llms.txt
Use this file to discover all available pages before exploring further.
when construct facilitates type checking by evaluating a subject against specified types using the is and !is operators. It integrates directly with Kotlin’s compiler-driven smart cast system, automatically casting the subject to the matched type within the lexical scope of the successful branch without requiring explicit cast operators (as).
Syntax
Technical Mechanics
1. Smart Casting and Scope When a branch condition likeis String evaluates to true, the compiler tracks this type assertion. Within the right-hand side of that specific branch, the subject is treated as the asserted type. Properties and functions of that type can be invoked immediately.
when block relies on the compiler’s ability to guarantee that the subject variable cannot change between the type check and its usage.
- It succeeds for local
valvariables, function parameters, andvalproperties of the same module without custom getters. - It succeeds for local
varvariables, provided the compiler can guarantee they are not modified between the type check and the usage, and they are not captured by a lambda that modifies them. - If the compiler cannot guarantee immutability (e.g., for mutable properties, open properties, or properties with custom getters), the
whenexpression and theischeck still compile and execute perfectly fine. It is only the smart cast that is denied. Compilation will only fail if the developer subsequently attempts to invoke methods or properties specific to the asserted type without manually casting it (as).
val directly inside the when subject parenthesis. Kotlin’s grammar fully supports explicit type annotations for this inline variable, though the type can also be inferred.
when expressions (where the result is assigned or returned). Since Kotlin 1.7, exhaustiveness is also strictly enforced for when statements if the subject is a sealed class, sealed interface, enum, or Boolean.
An else branch is required unless the provided branches exhaustively cover all possible types:
- Open Types: For open types (like standard non-sealed classes), an
elsebranch is generally required when the construct is used as an expression. The Kotlin compiler does not perform logical exhaustiveness checking for complementary checks (e.g.,is Stringand!is String). However, if the subject is of a non-nullable type, providing anis Anybranch does satisfy the compiler’s exhaustiveness requirement, and noelsebranch is needed (though the compiler will emit a warning that the check is always true). - Sealed Types: For
sealedclasses orsealedinterfaces, the compiler resolves all possible subtypes at compile time. If all subtypes are checked usingis, theelsebranch is safely omitted.
is or !is condition is met. If a subject implements multiple interfaces or inherits from multiple classes checked in the block, only the first matching branch executes.
Master Kotlin with Deep Grasping Methodology!Learn More





