> Le 4 janv. 2015 à 03:18, Rick Waldron <waldron.rick at gmail.com> a écrit :
> 
> 
> 
> On Sat Jan 03 2015 at 8:25:40 PM Brendan Eich <brendan at mozilla.org> wrote:
> Rick Waldron wrote:
> > That example above is pretty compelling for throw always consistency.
> 
> With a new Reflect.* API for converting a symbol to its
> diagnostic/debugging string?
> 
> If you agree, please file a bugs.ecmascript.org ticket.
> 
> 
> https://bugs.ecmascript.org/show_bug.cgi?id=3509
> 

I think that it is asking for the wrong consistency. There is another consistency to be wanted, namely:

   String(sym) === sym.toString()

(assuming that `Symbol.prototype.toString` isn't sabotaged by user code, of course). Indeed:

* `String(sym)` and `sym.toString()` are *explicit* coercions to string; while
* `sym + ""` triggers an *implicit* coercion to string (in that very case, preceded by a coercion to primitive, but it's not the subject).

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. 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). 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()`).

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.

—Claude

Le 4 janv. 2015 à 03:18, Rick Waldron <waldron.rick at gmail.com> a écrit :

> https://bugs.ecmascript.org/show_bug.cgi?id=3509

I think that it is asking for the wrong consistency. There is another consistency to be wanted, namely:

    String(sym) === sym.toString()

(assuming that `Symbol.prototype.toString` isn't sabotaged by user code, of course). Indeed:

* `String(sym)` and `sym.toString()` are *explicit* coercions to string; while
* `sym + ""` triggers an *implicit* coercion to string (in that very case, preceded by a coercion to primitive, but it's not the subject).

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. 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). 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()`).

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.