Why Kotlin Smart Cast Fails on Mutable Properties: var, Null Safety, and Elegant Fixes

By the end of this page, you will understand why Kotlin refuses to smart-cast mutable nullable properties, how this relates to null safety and possible state changes, and which common fixes are considered idiomatic in real Kotlin code.

Kotlin's smart cast feature lets the compiler treat a value as a more specific type after a check.

For example:

val name: String? = "Ada"
if (name != null) {
    println(name.length) // smart-cast to String
}

This works because name is stable inside that scope. Kotlin can prove that it has not changed between the null check and the use.

The problem in your example is that left is a mutable property:

var left: Node? = null

Because it is a var, Kotlin must assume it could change after the check, even if the code looks simple. A mutable property might be changed:

• by another method
• by another thread
• by a custom getter
• by code elsewhere in the same class

So in this code:

if (left != null) {
    queue.add(left)
}

Kotlin sees two separate reads of left:

1. one for left != null

Think of a mutable property like a note on a shared whiteboard.

You look at the whiteboard and see:

• left = Node(...)

A moment later, before you use it, someone else could erase it and write:

• left = null

So even though you checked it a second ago, you cannot trust the value unless you copy it somewhere stable.

A local val is like taking a photo of the whiteboard at that moment. That photo does not change.

val currentLeft = left
if (currentLeft != null) {
    queue.add(currentLeft)
}

Now the compiler is happy because currentLeft is stable.

The most common fixes are based on creating a stable local value or using Kotlin's null-safe operators.

1. Copy to a local val

var left: Node? = null

fun show() {
    val currentLeft = left
    if (currentLeft != null) {
        queue.add(currentLeft)
    }
}

Why it works:

• currentLeft is a local val
• it cannot change after assignment
• Kotlin can safely smart-cast it from Node? to Node

2. Use let

fun show() {
    left?.let { node ->
        queue.add(node)
    }
}

Why it works:

• left?.let { ... } only runs when left is non-null
• inside the lambda, node is non-null

Consider this version:

var left: Node? = Node(5)
val queue = mutableListOf<Node>()

fun show() {
    val node = left
    if (node != null) {
        queue.add(node)
    }
}

Step by step:

1. left starts as Node(5).
2. show() runs.
3. val node = left copies the current value of left into a local variable.
4. node now holds either:
   • a Node, or
   • null
5. if (node != null) checks the local variable.
6. Inside the if block, Kotlin knows node cannot be null.
7. queue.add(node) succeeds because is treated as , not .

This comes up often in Kotlin applications whenever you work with nullable mutable state.

UI state

A screen may hold mutable properties such as:

var selectedUser: User? = null

Before rendering or navigating, you often need a stable local copy.

Tree or graph structures

Your example uses a Node?, which is common in:

• binary trees
• parsers
• linked structures
• graph traversal

Child references are often nullable, so safe access patterns are important.

API response handling

var cachedResponse: Response? = null

Before reading fields from it, developers usually store a local snapshot or use ?.let.

Background and concurrent code

In multithreaded code, mutable shared properties really can change between check and use. Kotlin's rule helps prevent subtle bugs.

Event-driven apps

In Android, desktop apps, or servers, state may change due to callbacks or lifecycle events. A local val creates a safer point-in-time reference.

In real Kotlin codebases, developers usually solve this with a few standard patterns.

Guard clauses

A very common style is to exit early when the value is null:

fun show() {
    val node = left ?: return
    queue.add(node)
}

Benefits:

• less nesting
• clear intent
• easy to read

Safe-call with let

Useful when the action should happen only if the value exists:

fun show() {
    left?.let(queue::add)
}

This is concise and idiomatic.

Local snapshot for stability

When a property may be read multiple times, developers often capture it once:

fun process() {
    val current = left
    if (current != null) {
        use(current)
        log(current)
    }
}

This avoids repeated property reads.

Validation before work

1. Using !! to silence the compiler

Broken style:

fun show() {
    if (left != null) {
        queue.add(left!!)
    }
}

Why it is risky:

• !! throws NullPointerException if the value becomes null
• it bypasses Kotlin's safety checks

Use this only when you are absolutely certain and can justify it.

2. Assuming a null check always guarantees smart cast

Broken assumption:

var value: String? = "hello"
if (value != null) {
    println(value.length) // may fail to compile if value is not stable
}

A null check is not enough by itself. The variable must also be stable.

3. Re-reading mutable properties many times

if (left != null && left.value > 0) {
    queue.add(left)
}

This may lead to multiple compiler errors or unreadable code. Prefer a local snapshot:

// Problem
var left: Node? = null
if (left != null) {
    queue.add(left) // smart cast fails
}

Why it fails

• left is a mutable property (var)
• Kotlin sees two reads of left
• it could change between the null check and usage

Best fixes

val node = left
if (node != null) {
    queue.add(node)
}

left?.let { queue.add(it) }

val node = left ?: return
queue.add(node)

Prefer

• local val for stable snapshot
• ?.let for concise null handling
• ?: return for guard clauses

Avoid

Why does Kotlin not trust left after if (left != null)?

Because left is a mutable property. Kotlin cannot guarantee it still has the same value when it is read again.

Does this only happen with var?

Mostly, yes. Mutable properties are the common case. But some val properties also cannot be smart-cast if they have custom getters or are otherwise not stable.

What is the most idiomatic fix in Kotlin?

Usually one of these:

• val node = left ?: return
• left?.let { ... }
• copy to a local val

Is left!! a good fix?

It compiles, but it is usually not the best fix. It can throw NullPointerException at runtime.

Why does a local variable work better?

A local val is stable. Once assigned, it cannot change, so Kotlin can smart-cast it safely.

Is this related to multithreading?

Yes, that is one reason. But even without threads, Kotlin still applies the rule because mutable properties may change through other code paths.

• Kotlin null safety — Smart casts are part of Kotlin's approach to handling nullable and non-null types.
• val vs var — Understanding mutability is essential to understanding why smart casts sometimes fail.
• Safe calls (?.) — A common way to work with nullable values without manual null checks.
• Elvis operator (?:) — Useful for early returns and fallback values when dealing with nullable types.
• Scope functions (let) — Frequently used to work with nullable values in a concise way.
• Guard clauses — An important pattern for exiting early when required values are missing.
• Custom getters in Kotlin — These affect property stability and smart-cast behavior.
• NullPointerException in Kotlin — Helps explain why !! should be used carefully.