Implicit coercion of Symbols

[Brendan Eich]

Claude Pache wrote:
> Now, it will be argued that it would be a precedent to make such a distinction between implicit and explicit coercion, for, until ES5, there is none.

Kind of there all along, as noted up-thread:

js> o = {valueOf(){return 42}, toString(){return 'haha'}}
({valueOf:function valueOf(){return 42}, toString:function 
toString(){return 'haha'}})
js> String(o)
"haha"
js> ''+o
"42"

But I take your point.

> But, precisely, pervasive implicit coercion is often thought to be a mistake in the design of JavaScript (it hides bugs), while coercion in general is indeed useful (e.g., for debugging purpose, as pointed Alex in this thread).

*Explicit* coercion in general is useful. What's "explicit"? It could be 
console.log is an explicit-enough gesture. It does more than just 
ToString on its parameters today, IINM (at least in some browsers).

>   Now, as we are evolving the language, it is good to limit the scope of the bad implicit coercion behaviour (such as the abstract operation `ToString()` of the spec), but to consolidate the functionality of the existing explicit coercion functions (such as `String()`).

Yes, this is the rationale for ES6's symbol handling today.

> If there is a need to directly expose the implicit coercion to string operation to user code, `Reflect.toString()` is a natural fit for that, together with `Reflect.toBoolean()`, `Reflect.toPropertyKey()`,  `Reflect.toPrimitive(_, hint)`, etc.

Yup; ES7 fodder at this stage.

I think it's very unlikely anyone will try to patch ES6 over the 
trade-offs among consistencies that this thread has illuminated. Thanks,

/be