Go Type Conversion: When Truncation, Not Rounding, Strips Your Decimals
Go's truncation-on-conversion behavior is a common source of off-by-one and precision bugs when porting code from languages that round. Knowing that `ParseBool` accepts `1`/`0` and single-character `t`/`f` prevents brittle input validation that rejects valid configuration values.
Numeric type conversion in Go uses the type name as a function: `int(3.14)` yields `3`, discarding the decimal entirely. Every integer and float width gets its own conversion function, from `int8()` through `float64()`. The language refuses to mix strings and numbers in arithmetic, so `"10" + 20` is a compile error.
String-number conversion lives in the `strconv` package. `Itoa` (Int to ASCII) turns an integer into a string; `Atoi` (ASCII to Int) does the reverse and returns both a result and an error. Boolean conversion via `ParseBool` recognizes `1`, `t`, `T`, `TRUE`, `true`, and `True` as true, plus `0`, `f`, `F`, `FALSE`, `false`, and `False` as false — anything else fails. `FormatBool` produces only the lowercase strings `"true"` or `"false"`.
Five exercises walk through numeric truncation, `Itoa`/`Atoi` round-trips, `ParseBool` error handling, and a combined task that parses a price string and a discount flag, applies an 80% multiplier, and formats the result back to a string.
Go's choice to make type-name-as-function the conversion syntax keeps the language surface small but hides the truncation behavior behind a call that looks like a constructor — newcomers often expect rounding.
The `ParseBool` truth table is broader than many configuration parsers, which means a value like `1` from an environment variable will parse correctly where other languages might reject it.
Returning an error from `Atoi` and `ParseBool` forces explicit error handling, but the exercises show the common beginner pattern of discarding it with `_` — a habit that leads to silent zero-value bugs when input is malformed.