Perations Are Safe On A Nil Map
Fast recall
Quick revision
Core answer
Practical understanding of Map Iteration And Nil.
Repeating a definition without saying when to use it.
Give one trade-off and say how you would test it.
Interview-ready guide
Interview answer
The full inventory, nil map on the left of each:
var m map[string]int
len(m) // 0 — safe
cap-ish size // 0 — safe
m["key"] // 0, false — the zero value, safe
for k := range m // zero iterations — safe
delete(m, "k") // no-op — safe
m["k"] = 1 // PANIC: assignment to entry in nil mapOne operation panics; everything else answers as if the map were empty. The rule mirrors nil-map semantics generally: the map value is a pointer to the hash structure; nil points at nothing; reads and deletes can honestly report 'nothing there,' but a write needs somewhere to put the entry.
The bug pattern this creates is partial: functions that only read tolerate a nil map fine, so the defect hides until some later change adds a write. The defensive styles, in order of preference:
m := map[string]int{} // literal empty — write-ready from birth
m := make(map[string]int) // explicitThe empty literal is one type-safe expression that kills the whole bug class — there is no state of a map you can't write to after m := map[string]int{}.
Perations Are Safe On A Nil Map
Direct Answer
Reads (len, lookup → zero value), range (zero iterations), delete (no-op). Only writes panic.
Deep Dive & Architecture
The asymmetry is worth understanding rather than memorizing, because it's the same design decision appearing across Go. Consider the parallel with slices: a nil slice supports append (the allocate path creates storage on demand) — so 'var s []int; s = append(s, x)' is idiomatic. A nil map can't support 'insert on demand' for the same reason: creating a map's structure on demand would mean the write implicitly reassigns the map variable to a new pointer — but maps are passed by pointer already, and the runtime would have to reach into your variable to update it, which Go never does.
So the language's two collection types answer nil differently, each for a mechanical reason: the slice header is a value the runtime can return a new copy of (append's contract), while the map is a pointer whose replacement can only flow through assignment the caller performs. When people ask why Go is inconsistent here, that's the answer — it's not a philosophy difference, it's pointer-vs-value mechanics.
For API design, the consequence: functions that accept maps and might populate them should take-and-return (make inside, return the result) rather than fill-a-param — a nil map passed in can't be made writable from inside the function no matter what it does.
Common Mistakes & Pitfalls
Repeating a definition without saying when to use it.
Check your understanding
Answer these without looking back at the article.
- What is Map Iteration And Nil, and when would you use it?
- When would you use Map Iteration And Nil in a real project?
- What is a common mistake when using Map Iteration And Nil?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.