Elvis operator (?:) for default values in Kotlin - Deep Dive

Overview - Elvis operator (?:) for default values

What is it?

The Elvis operator ?: in Kotlin is a simple way to provide a default value when an expression is null. It checks if the value on the left is null; if it is, it returns the value on the right instead. This helps avoid errors caused by null values and makes code cleaner and easier to read. It's often used to handle nullable variables safely.

Why it matters

Without the Elvis operator, programmers would need to write longer code to check for null values and provide defaults, which can be error-prone and cluttered. The Elvis operator makes handling nulls concise and safe, preventing crashes and bugs in apps. It improves code readability and reduces the chance of forgetting to handle nulls, which can cause frustrating runtime errors.

Where it fits

Before learning the Elvis operator, you should understand Kotlin's nullable types and basic if-else statements. After mastering it, you can explore more advanced null safety features like the safe call operator (?.) and the let function for executing code only when values are not null.

Mental Model

Core Idea

The Elvis operator returns the left value if it’s not null; otherwise, it returns a default value on the right.

Think of it like...

Imagine you want to drink from a cup, but if the cup is empty, you grab a bottle instead. The cup is the first choice, and the bottle is the backup plan.

value ?: default_value

Where:
  value         - the expression that might be null
  ?:            - Elvis operator
  default_value - fallback if value is null

Build-Up - 7 Steps

1

Foundation

Understanding nullable types in Kotlin

Concept: Kotlin allows variables to hold null values only if declared nullable with a question mark.

In Kotlin, you declare a nullable variable by adding ? after the type, like String?. This means the variable can hold a string or null. For example: val name: String? = null Trying to use a nullable variable without checking for null causes errors.

Result

You can store null in variables declared with ?, but you must handle nulls carefully to avoid crashes.

Understanding nullable types is essential because the Elvis operator only works with values that might be null.

2

Foundation

Basic if-else null check

Concept: Before Elvis, you check if a value is null using if-else to provide a default.

To avoid null errors, you might write: val displayName = if (name != null) name else "Guest" This checks if name is null; if no, it uses name; otherwise, it uses "Guest" instead.

Result

You get a safe value to use, never null, but the code is longer and repetitive.

Manual null checks work but clutter code and distract from the main logic.

3

Intermediate

Using the Elvis operator for defaults

🤔Before reading on: do you think the Elvis operator returns the left value when it is null or not null? Commit to your answer.

Concept: The Elvis operator ?: returns the left value if it’s not null; otherwise, it returns the right value as a default.

Instead of if-else, you can write: val displayName = name ?: "Guest" If name is not null, displayName gets name; if name is null, displayName gets "Guest".

Result

Cleaner, shorter code that safely handles nulls with a default value.

Knowing that ?: is a concise null check helps write safer and more readable Kotlin code.

4

Intermediate

Chaining Elvis operators for multiple defaults

🤔Before reading on: do you think chaining multiple Elvis operators evaluates all defaults or stops at the first non-null? Commit to your answer.

Concept: You can chain ?: operators to try multiple fallback values until one is not null.

Example: val result = first ?: second ?: third ?: "No value" This tries first; if null, tries second; if null, tries third; if all null, uses "No value".

Result

You get the first non-null value from a chain of options, making complex defaults easy.

Understanding short-circuit evaluation in ?: chains prevents unnecessary checks and improves performance.

5

Intermediate

Combining Elvis with safe call operator

🤔Before reading on: do you think the Elvis operator can be used after a safe call to handle null results? Commit to your answer.

Concept: The Elvis operator works well with the safe call operator ?. to handle nullable expressions safely.

Example: val length = name?.length ?: 0 Here, name?.length returns length if name is not null; else null. ?: then provides 0 as default.

Result

You safely get a value even when parts of the expression might be null, avoiding crashes.

Knowing how ?: and ?. combine lets you write concise, safe code that handles nulls at multiple levels.

6

Advanced

Elvis operator with smart casting

🤔Before reading on: do you think the Elvis operator affects Kotlin’s smart casting of nullable types? Commit to your answer.

Concept: Using ?: can help Kotlin smart cast nullable variables to non-null after the operator, simplifying code.

Example: val nonNullName = name ?: return println(nonNullName.length) Here, if name is null, the function returns early. Otherwise, nonNullName is smart cast to non-null String.

Result

You avoid explicit null checks and safely use variables as non-null after Elvis checks.

Understanding smart casting with ?: helps write cleaner control flow without verbose null checks.

7

Expert

Performance and bytecode of Elvis operator

🤔Before reading on: do you think the Elvis operator compiles to multiple if-else checks or a single efficient bytecode instruction? Commit to your answer.

Concept: The Elvis operator compiles into efficient JVM bytecode using conditional jumps, minimizing runtime overhead.

Under the hood, ?: compiles to a conditional jump that checks if the left value is null and jumps to load the right value if needed. This is more efficient than multiple if-else statements. Example bytecode snippet: ALOAD_1 IFNONNULL label1 ALOAD_2 label1: ...

Result

The Elvis operator is both concise in code and efficient in execution.

Knowing the efficient compilation of ?: reassures you that concise code does not sacrifice performance.

Under the Hood

At runtime, the Elvis operator evaluates the left expression first. If it is not null, that value is returned immediately. If it is null, the right expression is evaluated and returned. This is implemented using conditional branching in the compiled bytecode, which checks for null and jumps accordingly. This lazy evaluation ensures the right side is only computed if needed.

Why designed this way?

The Elvis operator was introduced to simplify null handling, a common source of bugs and verbose code. It was designed to be concise and readable, reducing boilerplate null checks. The choice to evaluate the right side lazily avoids unnecessary computation, improving performance and side-effect control. Alternatives like explicit if-else were more verbose and error-prone.

┌───────────────┐
│ Evaluate left │
│ expression    │
└──────┬────────┘
       │
       ▼
┌───────────────┐   No
│ Is left null? ├─────────────┐
└──────┬────────┘             │
       │Yes                   │
       ▼                      ▼
┌───────────────┐       ┌───────────────┐
│ Evaluate right│       │ Return left   │
│ expression    │       │ value        │
└───────────────┘       └───────────────┘
       │
       ▼
┌───────────────┐
│ Return right  │
│ value         │
└───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does the Elvis operator evaluate the right side even if the left side is not null? Commit to yes or no.

Common Belief: The right side of ?: is always evaluated regardless of the left side.

Reality: The right side is only evaluated if the left side is null, making ?: a lazy operator on the right side.

Why it matters: If you assume the right side always runs, you might write expensive or side-effect code there unnecessarily, hurting performance or causing bugs.

Quick: Can the Elvis operator be used with non-nullable types? Commit to yes or no.

Common Belief: You can use ?: with any type, nullable or not.

Reality: The Elvis operator is meaningful only with nullable types; using it with non-nullable types is redundant and often flagged by the compiler.

Why it matters: Misusing ?: with non-nullables can confuse readers and clutter code without benefit.

Quick: Does chaining multiple Elvis operators always evaluate all right-side expressions? Commit to yes or no.

Common Belief: All right-side expressions in a chain of ?: are evaluated every time.

Reality: Evaluation stops at the first non-null value; later right sides are not evaluated.

Why it matters: Understanding this prevents unexpected side effects and improves performance by avoiding unnecessary computations.

Quick: Does the Elvis operator change the type of the expression it returns? Commit to yes or no.

Common Belief: The Elvis operator can change the type of the expression it returns.

Reality: The resulting type is the common supertype of both sides; it does not arbitrarily change types.

Why it matters: Incorrect assumptions about type changes can cause type mismatch errors or unsafe casts.

Expert Zone

1

The right side of ?: can be any expression, including function calls or complex computations, but it’s only evaluated if needed, enabling lazy defaults.

2

When used with smart casting, ?: can help Kotlin infer non-null types after null checks, reducing explicit casts and improving code safety.

3

In coroutines or inline functions, the Elvis operator preserves suspension points and inlining behavior, which can affect performance and debugging.

When NOT to use

Avoid using ?: when you need to handle nulls with complex logic or side effects; instead, use if-else or when expressions. Also, for chaining many nullable operations, consider using safe calls with let or run for clearer intent.

Production Patterns

In production Kotlin code, ?: is widely used for providing default values in configuration loading, user input handling, and API responses. It’s often combined with safe calls to write concise, null-safe chains. Developers also use it to return early from functions when a required value is missing.

Connections

Null coalescing operator in C#

Equivalent operator in another language

Understanding ?: in Kotlin helps grasp similar null-handling operators like ?? in C#, showing a common pattern across languages.

Ternary conditional operator (?:) in JavaScript

Similar syntax but different purpose

Knowing the difference between Kotlin’s Elvis operator and JavaScript’s ternary operator prevents confusion despite similar symbols.

Fallback mechanisms in human decision-making

Conceptual similarity in choosing alternatives

Recognizing how humans pick backup options when primary choices fail mirrors how ?: provides defaults, linking programming logic to everyday reasoning.

Common Pitfalls

#1 Using the Elvis operator with a non-nullable variable unnecessarily.

Wrong approach:

val name: String = "Alice"
val displayName = name ?: "Guest"

Correct approach:

val name: String = "Alice"
val displayName = name

Root cause:

Misunderstanding that ?: is only needed for nullable types leads to redundant code.

#2 Placing expensive function calls on the right side without realizing they always run.

Wrong approach:

val displayName = name ?: expensiveFunction()

Correct approach:

val displayName = name ?: expensiveFunction() // This is correct because expensiveFunction() runs only if name is null

Root cause:

Confusing eager and lazy evaluation of the right side causes unnecessary performance concerns.

#3 Expecting all right-side expressions in a chain to execute.

Wrong approach:

val result = first ?: secondFunction() ?: thirdFunction()

Correct approach:

val result = first ?: secondFunction() ?: thirdFunction() // Only until first non-null is found

Root cause:

Not understanding short-circuit evaluation leads to wrong assumptions about side effects.

Key Takeaways

The Elvis operator ?: provides a concise way to supply default values when dealing with nullable types in Kotlin.

It evaluates the left expression first and only evaluates the right expression if the left is null, ensuring efficient and safe code.

Combining ?: with safe calls ?. allows for elegant handling of complex nullable chains without verbose null checks.

Understanding how ?: compiles to efficient bytecode reassures that concise code does not sacrifice performance.

Misusing ?: with non-nullable types or misunderstanding its evaluation can lead to redundant code or unexpected behavior.