Why does `const s = Symbol('id'); console.log('id: ' + s);` throw in JavaScript, while `String(s)` returns a string?

## The behaviour ```js const s = Symbol('id'); 'id: ' + s; // TypeError: Cannot convert a Symbol value to a string `${s}`; // TypeError — same reason 'x'.concat(s); // TypeError String(s); // 'Symbol(id)' ✅ s.toString(); // 'Symbol(id)' ✅ s.description; // 'id' ✅ +s; // TypeError: Cannot convert a Symbol value to a number s > 1; // TypeError Boolean(s); // true — never throws !s; // false ``` So of the three coercion targets, symbols behave differently in each: string conversion throws implicitly but has explicit escape hatches, number conversion throws with no escape hatch at all, and boolean conversion always succeeds with `true`. ## Why the spec throws The reasoning is the whole purpose of the type. A symbol is meant to be a property key that cannot collide with a string key. Suppose implicit coercion produced `'Symbol(id)'` instead of throwing: ```js const ID = Symbol('id'); const obj = {}; obj[ID] = 1; // symbol key obj['Symbol(id)'] = 2; // an ordinary string key — and now, a collision ``` Worse, the collision would be silent and would depend on a *description* that was supposed to be debug-only. Two libraries whose symbols both describe themselves as `'id'` would suddenly share a slot. Making the conversion throw forces the mistake to surface at the point where it happens, loudly, rather than as corrupted data three layers away. This is one of the rare places where JavaScript chose a hard error over a coercion, and the reason is that the alternative would silently defeat a language feature. ## Why `String()` is allowed anyway `String(value)` contains an explicit carve-out: if the argument is a symbol, it returns `SymbolDescriptiveString(value)` — `'Symbol('` + description + `')'` — instead of running the ordinary ToString algorithm. `Symbol.prototype.toString()` does the same. The distinction the spec is drawing is **intent**: `String(s)` is unambiguous — you asked for the debug text and you will get it. `'x' + s` is ambiguous — the programmer very likely does not realise a symbol is in the expression at all. Note that `String(s)` and `new String(s)` differ: the latter throws, because construction runs the ordinary ToString path. ## The template-literal trap The most common way to hit this in real code is logging: ```js console.log(`key = ${s}`); // 💥 TypeError at runtime console.log('key =', s); // fine — console does not coerce console.log(`key = ${String(s)}`); // fine console.log(`key = ${s.description}`); // fine, prints 'id' ``` A template literal applies ToString to every substitution, so it throws exactly like `+`. Passing the symbol as a separate `console.log` argument does not coerce it at all, which is why the bug often survives development and only appears once someone rewrites a log line into a template. ## What does *not* throw - **Boolean coercion.** Symbols are objects-of-interest to nobody's falsiness table: `Boolean(sym)` is `true`, so guards like `if (key)` work. - **Equality.** `s === s` and `s == s` are fine; comparison never coerces a symbol. But `s == 'Symbol(id)'` is simply `false`, not an error — loose equality with a string does not attempt symbol-to-string conversion. - **Use as a property key.** `obj[s]` uses the symbol as a key directly; no conversion happens, which is precisely the case the whole rule protects. - **`JSON.stringify`.** It does not throw on symbols; it silently omits them (or emits `null` for an array element). ## Diagnosing it The message — `Cannot convert a Symbol value to a string` in V8, wording varies by engine — is specific enough that it names the cause outright. When you see it, look for a template literal, a `+`, or a string method applied to something that turned out to be a symbol; the usual culprit is a value that came from `Reflect.ownKeys` or `Object.getOwnPropertySymbols` and was then interpolated into a message. The fix is always the same: convert explicitly with `String(key)`, or use `key.description` when you want just the label without the `Symbol(...)` wrapper. ## Version note This behaviour has been in the language since symbols were introduced in ES2015. The `description` accessor is the newer part, added in ES2019; before it, `sym.toString().slice(7, -1)` was the idiom.