The Kotlin Type System

Keywords

ver. 1.0.0

Kotlin’s type system: null-safety, primitives/boxing, special types, and collection mutability — including how Java interop affects them.

This unit teaches Kotlin’s type-level safety: how nullability is encoded in types and enforced by the compiler, the four nullable-handling operators (?., ?:, as?, !!), and auxiliary tools like let, lateinit, and nullable receivers. It explains platform types at the Java boundary, Kotlin’s unified primitive/wrapper model and explicit numeric conversions, the roles of Any, Unit, and Nothing, the distinction between read-only and mutable collection interfaces, and when to use arrays (including primitive arrays) for interop or vararg.

Full summary

The unit builds the concrete type-system machinery that makes Kotlin “safe” with respect to nulls and other JVM interop concerns. It starts by making nullability part of the type system: a type like String is non-nullable and String? is nullable — two distinct types — so the compiler prevents operations that could cause a NullPointerException, shifting errors from runtime to compile time.

You learn the four primary nullable-handling operators and when to use each: - ?. (safe call): invoke a member only if the receiver is non-null, otherwise produce null. - ?: (Elvis): provide a default when the left side is null. - as? (safe cast): return null instead of throwing on a failed cast. - !! (not-null assertion): force a nullable value to non-null and crash if wrong.

Beyond those, the unit shows idioms that avoid repetitive null checks: let used with ?. to run a block only on non-null values, lateinit for deferred initialization of non-null properties (useful for frameworks), and extension functions whose receiver type itself can be nullable, letting you call methods without an extra safe call.

Interoperability with Java is covered in depth: Java provides no nullability annotations as far as the type system is concerned, so Kotlin introduces platform types — types for which the compiler trusts the programmer rather than enforcing nullability. This design balances ergonomics and safety at the Java boundary.

The unit explains Kotlin’s approach to primitives and boxing: Kotlin exposes a single type (e.g., Int) and the compiler emits JVM primitives where possible, boxing only when required. A key rule is that numeric conversions are always explicit — there are no implicit widening conversions (you must call toLong() etc.), a deliberate choice to avoid accidental loss of information.

It places the three special types clearly: - Any is the non-nullable root (like Object without null). - Unit replaces void but is a real type with a value, which matters for generics and function types. - Nothing denotes expressions that never return (e.g., throw), enabling patterns like using throw on the right-hand side of an Elvis operator.

Collections are split into read-only and mutable interfaces: Collection (read-only view) vs MutableCollection (modifiable). Declaring a parameter as the read-only interface guarantees you will only read from it, but read-only is not the same as immutable — another reference could still mutate the underlying collection.

Finally, arrays are introduced: Array<T> (which boxes primitives) and specialized primitive arrays like IntArray to avoid boxing. Arrays are less common in idiomatic Kotlin than in Java, but you need them for Java interop and for vararg parameters.

By the end of the unit a learner will be able to declare nullable and non-nullable types and understand what the compiler disallows, apply the nullable operators and helper idioms (let, lateinit, nullable receivers), reason about and defend against Java platform types, predict when boxing occurs and perform explicit numeric conversions, use Any/Unit/Nothing appropriately, choose between read-only and mutable collection interfaces, and decide when to use arrays (and primitive arrays) for interop or vararg use. The next topic is how familiar operator syntax maps to function calls (operator overloading and conventions).

Materials

Lecture notesThe unit written out, to read at your own paceOpen → SlidesThe deck to present fromOpen →

Source document

Kotlin in Action, Second Edition, Sebastian Aigner, Roman Elizarov, Svetlana Isakova, and Dmitry Jemerov, Manning, April 2024 — Link — Page 154-196

← Programming with Lambdas Operator Overloading and Other Conventions →

--- title: "The Kotlin Type System" keywords: - ver. 1.0.0 format: html: toc: false --- **Kotlin's type system: null-safety, primitives/boxing, special types, and collection mutability — including how Java interop affects them.** > This unit teaches Kotlin's type-level safety: how nullability is encoded in types and enforced by the compiler, the four nullable-handling operators (?., ?:, as?, !!), and auxiliary tools like `let`, `lateinit`, and nullable receivers. It explains platform types at the Java boundary, Kotlin's unified primitive/wrapper model and explicit numeric conversions, the roles of `Any`, `Unit`, and `Nothing`, the distinction between read-only and mutable collection interfaces, and when to use arrays (including primitive arrays) for interop or `vararg`. ::: {.callout-note collapse="true" title="Full summary"} The unit builds the concrete type-system machinery that makes Kotlin "safe" with respect to nulls and other JVM interop concerns. It starts by making nullability part of the type system: a type like `String` is non-nullable and `String?` is nullable — two distinct types — so the compiler prevents operations that could cause a NullPointerException, shifting errors from runtime to compile time. You learn the four primary nullable-handling operators and when to use each: - `?.` (safe call): invoke a member only if the receiver is non-null, otherwise produce null. - `?:` (Elvis): provide a default when the left side is null. - `as?` (safe cast): return null instead of throwing on a failed cast. - `!!` (not-null assertion): force a nullable value to non-null and crash if wrong. Beyond those, the unit shows idioms that avoid repetitive null checks: `let` used with `?.` to run a block only on non-null values, `lateinit` for deferred initialization of non-null properties (useful for frameworks), and extension functions whose receiver type itself can be nullable, letting you call methods without an extra safe call. Interoperability with Java is covered in depth: Java provides no nullability annotations as far as the type system is concerned, so Kotlin introduces platform types — types for which the compiler trusts the programmer rather than enforcing nullability. This design balances ergonomics and safety at the Java boundary. The unit explains Kotlin's approach to primitives and boxing: Kotlin exposes a single type (e.g., `Int`) and the compiler emits JVM primitives where possible, boxing only when required. A key rule is that numeric conversions are always explicit — there are no implicit widening conversions (you must call `toLong()` etc.), a deliberate choice to avoid accidental loss of information. It places the three special types clearly: - `Any` is the non-nullable root (like `Object` without null). - `Unit` replaces `void` but is a real type with a value, which matters for generics and function types. - `Nothing` denotes expressions that never return (e.g., `throw`), enabling patterns like using `throw` on the right-hand side of an Elvis operator. Collections are split into read-only and mutable interfaces: `Collection` (read-only view) vs `MutableCollection` (modifiable). Declaring a parameter as the read-only interface guarantees you will only read from it, but read-only is not the same as immutable — another reference could still mutate the underlying collection. Finally, arrays are introduced: `Array<T>` (which boxes primitives) and specialized primitive arrays like `IntArray` to avoid boxing. Arrays are less common in idiomatic Kotlin than in Java, but you need them for Java interop and for `vararg` parameters. By the end of the unit a learner will be able to declare nullable and non-nullable types and understand what the compiler disallows, apply the nullable operators and helper idioms (`let`, `lateinit`, nullable receivers), reason about and defend against Java platform types, predict when boxing occurs and perform explicit numeric conversions, use `Any`/`Unit`/`Nothing` appropriately, choose between read-only and mutable collection interfaces, and decide when to use arrays (and primitive arrays) for interop or `vararg` use. The next topic is how familiar operator syntax maps to function calls (operator overloading and conventions). ::: ## Materials ::: {.hg-deck} <a class="hg-card" href="notes.qmd">Lecture notesThe unit written out, to read at your own paceOpen →</a> <a class="hg-card" href="slides.qmd">SlidesThe deck to present fromOpen →</a> ::: ## Source document - Kotlin in Action, Second Edition, _Sebastian Aigner, Roman Elizarov, Svetlana Isakova, and Dmitry Jemerov_, Manning, April 2024 — [Link](https://www.manning.com/books/kotlin-in-action-second-edition) — Page 154-196 ::: {.hg-nav} [← Programming with Lambdas](../5_programming_with_lambdas/index.qmd){.hg-prev} [Operator Overloading and Other Conventions →](../7_operator_overloading_and_conventions/index.qmd){.hg-next} :::