debug a problem involving Type Conversion Vs Assertion
Fast recall
Quick revision
Core answer
Practical understanding of Type Conversion Vs Assertion.
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 conversion, not the intuition:
string(42) // "*" — code point 42 is the '*' character
string(65) // "A"
string(233) // "é"
strconv.Itoa(42) // "42" — the DECIMAL DIGITSExecuted in the earlier conversion verification: string(rune(65)) gave "A". The string() conversion takes a rune — a Unicode code point — and yields that code point's CHARACTER. 42 IS a valid code point (the '*' character in ASCII), so the conversion succeeds, silently, with a surprising result.
Why the language works this way: string↔rune is the UTF-8 encode/decode pair (string('é') encodes é's UTF-8 bytes; []rune(s) decodes them). The rune conversion is the character-level bridge; the NUMBER-to-digits bridge is strconv's parsing/formatting world. Two different jobs, two different mechanisms — and the compiler can't distinguish intent: string(42) is well-typed (int converts to rune/int32).
The defenses: go vet's strconfmt check flags string(int) patterns with 'conversion from int to string yields a string of one rune' — one of the few checks dedicated to a single conversion trap; and the discipline: digits come from strconv.Itoa / fmt.Sprintf, never from string().
The historical note: pre-Go-1.15, string(int) sometimes even produced invalid UTF-8 (values past valid code point ranges); the language later specified the replacement-character behavior for out-of-range ints — the trap was bad enough that the spec itself was tightened.
debug a problem involving Type Conversion Vs Assertion
Direct Answer
string() converts a RUNE (int32 code point) to its character — 42 is code point 42 (''), so string(42) is "". For digits, use strconv.Itoa(42). The classic Go beginner trap — go vet flags it.
Deep Dive & Architecture
The rune conversion's mechanics, precisely: string(r) encodes the code point r as its UTF-8 sequence — for 42 (a 1-byte code point), the byte 42 ('*'). The conversion result for out-of-range values (negative, past 0x10FFFF, or surrogate range): the spec (Go 1.15+) says the result is U+FFFD (replacement character) — the runtime clamps invalids rather than producing invalid UTF-8, closing the earlier hole where string(-1) yielded an invalid byte string.
Why the compiler doesn't just reject string(int): int→rune→string is a legal chain (int is convertible to int32, int32 to string via the rune rule), and blocking string(intValue) would break legitimate rune-from-int code (string(rune(i)) — the explicitly-correct idiom). go vet's check threads the needle: it flags string(x) where x's type is an INTEGER (the accidental case) while passing string(rune(x)) (the explicit case) — pattern recognition in the linter doing what the type system can't.
The inverse trap, one last mirror: []byte("42") is [52 50] (the DIGITS' bytes), not [4 2] (the numbers) — the same category error in the other direction (expecting the conversion to parse). The family of bugs — string(42), []byte(42), int("42") — all one misunderstanding: conversions transform ENCODINGS, parsers interpret SEMANTICS. Go splits the world: T(x) for encodings, strconv for semantics, and every one of these bugs is crossing the line with the wrong tool.
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 Type Conversion Vs Assertion, and when would you use it?
- When would you use Type Conversion Vs Assertion in a real project?
- What is a common mistake when using Type Conversion Vs Assertion?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.