Null safety

The operators

1data class Address(val city: String?)2data class User(val name: String, val address: Address?)3 4fun cityOf(user: User?): String =5    user?.address?.city ?: "unknown"          // safe calls, then a fallback6 7fun requireCity(user: User): String {8    val city = user.address?.city ?: return "no city"   // Elvis can return or throw9    return city.uppercase()                   // city is String here10}11 12fun main() {13    println(cityOf(User("Ada", Address("London"))))   // London14    println(cityOf(User("Bob", null)))                  // unknown15    println(cityOf(null))                               // unknown16    println(requireCity(User("Cy", Address(null))))     // no city17}

• a?.b is null if a is null, otherwise a.b. A chain stops at the first null.
• a ?: b is a unless it is null, then b. Because return and throw are expressions, the right side can leave the function early, which keeps the rest of the code flat.
• a!! throws a NullPointerException if a is null. Use it only where a null really is a bug, and prefer checkNotNull(a) { "why" } or requireNotNull, which explain the failure.

Smart casts

After a null check the compiler narrows the type for you:

1fun describe(text: String?) {2    if (text == null) return3    println(text.length)      // smart cast: text is String from here on4}

That only works on values that can't change between the check and the use: local vals, local vars not captured by a lambda that modifies them, and val properties that are not open, have no custom getter and are declared in the same module. For a mutable property, copy it into a local first, or write owner?.let { ... }.

Where null sneaks back in

• Platform types. A value from Java without nullability annotations has a type written String! in the IDE: Kotlin lets you treat it as either. If you choose non-null and it is null, it fails at the point of use. Annotated Java (JSpecify, JetBrains, AndroidX annotations) gives you proper Kotlin types instead.
• lateinit var. A promise that a non-null property will be set before it is read; reading it early throws UninitializedPropertyAccessException. Good for dependency injection and test setup, risky elsewhere. ::prop.isInitialized checks it.
• Initialisation order. Calling an open method from a constructor can let a subclass see its own properties before they are set, so a non-null property can be null for a moment.
• Generics. A type parameter T can itself be nullable (T is Any? by default). Write T : Any to forbid it.

Collections have their own pair of question marks: List<String?> is a list that may contain nulls, List<String>? is a list that may be missing. filterNotNull() and mapNotNull() turn the first into a List<String>.