Conversion, Coercion & Parsing at the Boundary

Three different operations get called "conversion" and behave nothing alike: widening (always safe, information-preserving), narrowing (may destroy information, so somebody must decide what happens when it does), and parsing (turning text into a value, which can simply fail). Languages differ mostly in how loudly they make you acknowledge the second and third. The bugs cluster exactly where the language stays quiet.

Widening, narrowing, and who checks #

Widening conversions — int → long, float → double, subclass → superclass — are implicit everywhere because no value is lost. Narrowing is where the design choice lives.

long  big = 3_000_000_000L;
int   n   = (int) big;   // -1294967296 — silently wraps, no exception
double d  = 1.9;
int   m   = (int) d;     // 1 — truncates toward zero, not rounds

Java, C, C++, C# (unchecked) and Go all truncate silently on integer narrowing. The alternatives exist and are worth knowing:

Implicit coercion #

Coercion is conversion the language performs on your behalf to make an operation type-check. It is convenient in the small and produces tables like this in the large:

[] + {}        // "[object Object]"   — both coerced to string
[] == false    // true   — [] → "" → 0, false → 0
"0" == false   // true
"" == 0        // true
null == 0      // false  — null only loosely equals undefined
NaN == NaN     // false
[1,10,2].sort() // [1,10,2] → compares "1" < "10" < "2" as strings

None of this is random — it is ToPrimitive followed by the abstract equality algorithm in ECMA-262 — but no one holds it in their head, which is why the practical rule in JavaScript and TypeScript is: use === always, and use an explicit Number()/String() when you want a conversion.

Python 3 took the opposite path deliberately: 1 + "1" is a TypeError, and that break with Python 2 was one of the migration's biggest costs and one of its clearest wins.

Casting is not parsing #

A cast re-describes a value the program already has, at compile time or with a runtime identity check. Parsing builds a value from external text and can legitimately fail.

object o = "42";
int a = (int) o;                       // InvalidCastException — a string is not a boxed int
int b = int.Parse("42");               // parse — throws on bad input
bool ok = int.TryParse(s, out int c);  // parse — returns failure instead of throwing

The distinction matters because they need different error handling. A failed cast is a programming error — the code believed something false about its own data. A failed parse is an expected outcome of untrusted input, and code that treats it as exceptional will either crash on ordinary bad input or swallow it. See error handling strategies.

Floating point deserves its own caution #

double holds integers exactly only up to $2^{53}$. Beyond that, converting a 64-bit integer to a double loses low bits silently — which is why JSON, whose number type is a double in most parsers, cannot round-trip a 64-bit ID. Twitter hit this in 2010 and the standard fix has been the same ever since: serialize 64-bit identifiers as strings.

{ "id": 10765432100123456789, "id_str": "10765432100123456789" }

$0.1 + 0.2 \neq 0.3$ for the same reason — neither operand is representable in binary. Money is never a float; it is an integer count of minor units or a decimal type (floating-point hardware).