Val for immutable references in Kotlin - Time & Space Complexity
Let's explore how using val for immutable references affects the time complexity of Kotlin code.
We want to see if immutability changes how long the program takes to run as input grows.
Analyze the time complexity of the following code snippet.
fun sumList(numbers: List): Int {
var total = 0
for (num in numbers) {
val current = num
total += current
}
return total
}
This code sums all numbers in a list using val for immutable references inside the loop.
Identify the loops, recursion, array traversals that repeat.
- Primary operation: Looping through each number in the list.
- How many times: Once for every item in the list.
As the list gets bigger, the loop runs more times, doing the same steps each time.
| Input Size (n) | Approx. Operations |
|---|---|
| 10 | About 10 steps |
| 100 | About 100 steps |
| 1000 | About 1000 steps |
Pattern observation: The work grows directly with the number of items.
Time Complexity: O(n)
This means the time to finish grows in a straight line as the list gets bigger.
[X] Wrong: "Using val makes the code slower because it creates new variables every time."
[OK] Correct: val just means the reference can't change, but it doesn't add extra loops or slow down the main work. The main time depends on how many items we process.
Understanding how immutability affects performance helps you write clear and efficient code, a skill that shows you think carefully about your programs.
"What if we replaced the val inside the loop with var? How would the time complexity change?"
Practice
val keyword do in Kotlin?Solution
Step 1: Understand the role of
valvaldeclares a variable whose reference cannot be changed after assignment.Step 2: Compare with other keywords
varallows reassignment, butvaldoes not.Final Answer:
Creates an immutable reference that cannot be reassigned -> Option BQuick Check:
val= immutable reference [OK]
- Confusing val with var
- Thinking val makes the object itself immutable
- Assuming val declares a function or class
count with value 10 in Kotlin?Solution
Step 1: Identify correct keyword and syntax
valis used for immutable variables, and Kotlin infers type if not specified.Step 2: Check each option
var count = 10 usesvar(mutable), C has invalid syntax, D is incomplete.Final Answer:
val count = 10 -> Option AQuick Check:
Immutable variable syntax = val count = 10 [OK]
- Using var instead of val for immutable variables
- Incorrect Kotlin type declarations
- Leaving declarations incomplete
val list = mutableListOf(1, 2, 3) list.add(4) println(list)
Solution
Step 1: Understand val with mutable objects
valmeans the reference to the list cannot change, but the list itself can be modified.Step 2: Analyze code behavior
Adding 4 to the mutable list changes its content, so printing shows [1, 2, 3, 4].Final Answer:
[1, 2, 3, 4] -> Option DQuick Check:
val reference + mutable object = modified list [OK]
- Thinking val prevents modifying the list content
- Expecting compilation or runtime errors
- Confusing immutable reference with immutable object
val number = 5 number = 10 println(number)
Solution
Step 1: Check reassignment of val variable
valvariables cannot be reassigned after initialization.Step 2: Identify error type
Trying to assign 10 tonumbercauses a compilation error.Final Answer:
Compilation error: val cannot be reassigned -> Option CQuick Check:
val reassignment = compilation error [OK]
- Assuming val variables can be reassigned
- Confusing runtime errors with compile errors
- Ignoring Kotlin's no-semicolon rule
val map = mutableMapOf("a" to 1, "b" to 2)
map["a"] = 3
println(map)Explain why this works even though
map is declared with val.Solution
Step 1: Understand val with mutable collections
valmeans the reference to the map cannot change, but the map's content can be modified.Step 2: Analyze the map update
Updating key "a" to 3 changes the map content, so printing shows {a=3, b=2}.Final Answer:
{a=3, b=2} -> Option AQuick Check:
val reference + mutable map = updated map content [OK]
- Thinking val prevents modifying map content
- Expecting compilation or runtime errors
- Confusing immutable reference with immutable object
Ready to prove it?
Pass the test and this pattern moves unknown
