Go's blank identifier: meaning and behaviour
Fast recall
Quick revision
Core answer
_. It receives a value and immediately discards it, which lets Go code intentionally ignore a return value or one value produced by range. _ is not a normal variable: its value cannot be read later. It should communicate that a value is deliberately unused, not hide information the program should handle.Explain the blank identifier in plain language, walk through one small Go example, and name the main boundary or limitation.
Listing syntax without explaining what the program stores or does.
Connect the definition to one realistic use and one important limitation.
Interview-ready guide
Interview answer
The blank identifier is written as
_. It receives a value and immediately discards it, which lets Go code intentionally ignore a return value or one value produced byrange._is not a normal variable: its value cannot be read later. It should communicate that a value is deliberately unused, not hide information the program should handle.For example: the range index is intentionally ignored, so
_is clear and safe. Ignoring the parsing error is different because invalid input then becomes indistinguishable from a valid zero. The code keeps the behaviour visible without unrelated setup.Use
_for an unneeded range index or value, for an intentionally ignored return value only when failure is impossible or irrelevant, and for compile-time interface assertions such asvar _ io.Reader = (*File)(nil). That choice keeps the data model and the code's intention aligned.The dangerous mistake is using
_to silence an error. The code may continue with a zero or partial result and fail later, far from the real cause. Name and handle errors, keep_for truly irrelevant values, and add a comment when a side-effect import or deliberate discard is not obvious.
Go's blank identifier: meaning and behaviour
Direct Answer
The blank identifier is written as _. It receives a value and immediately discards it, which lets Go code intentionally ignore a return value or one value produced by range. _ is not a normal variable: its value cannot be read later. It should communicate that a value is deliberately unused, not hide information the program should handle.
Deep Dive & Architecture
When a valid-looking zero appears unexpectedly, search for discarded errors or values near parsing, I/O, type assertions, and database calls.
Restore the named value and handle it at the source.
Check every multi-value call that uses _, range loops that may need the missing index, and blank imports that change program startup. Test invalid input as well as valid input, and assert that the original error is returned or wrapped instead of silently becoming a zero result.
The dangerous mistake is using _ to silence an error. The code may continue with a zero or partial result and fail later, far from the real cause. Name and handle errors, keep _ for truly irrelevant values, and add a comment when a side-effect import or deliberate discard is not obvious.
Code Example
for _, name := range names {
fmt.Println(name)
}
value, _ := strconv.Atoi(input) // unsafe if the error matters
Common Mistakes & Pitfalls
Listing syntax without explaining what the program stores or does.
Check your understanding
Answer these without looking back at the article.
- How do the blank identifier compare with a named variable in Go?
- When should you use the blank identifier in Go?
- What common mistakes should you avoid with the blank identifier in Go?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.