See discussion here: https://esdiscuss.org/topic/implicit-coercion-of-symbols
Relevant discussion: https://esdiscuss.org/topic/string-symbol
If we do that, we should consider making `Symbol.prototype.toString()` throw as well for consistency.
Sort of want to bring up what I was saying in comment 22:
While it's fine to have a Reflect API specifically for converting a Symbol to a string, is there any reason why we couldn't have it generalized for all primitive types?
It would be really cool if there were a guaranteed side-effect-free method for converting value types to strings.
For Object types, it's a bit more complicated to get a side-effect-free stringifier, but I don't see any reason why that couldn't be done (eg internal class name / class binding identifier / function binding identifier / fallback strings for these values).
In short, Reflect.toString(O) (or whatever it's called) should always do the right thing, and always be side-effect-free, should never be customizable. This would have advantages for VMs which could inline specific R.toString calls for specific types.
Just a thought, but I think valueOf and toString and @@toStringTag are problematic enough due to the potential side effects, so it would be awesome to have a useful alternative which never suffered from these.
This has already been consider by TC39. This is a black and white situation where one of the alternatives is clearly better than the alternative.
Given that, I don't think we need to revisit the current TX39 decision at this late date in ES6 development.
Allen, agree it's quite late and we have bigger fish to fry, but one alternative beating another when there are three alternatives doesn't explain the status quo.
Alternative 1 (current ES6 draft spec): ''+sym throws, String(sym) works.
Alternative 2: both work -- a non-starter, everyone agrees to this, I think.
Alternative 3: both throw, and Reflect.describe gets fast-tracked somehow. This is the alternative people cc'ed here favor, and TC39 has never evaluated it or rejected it as clearly worse, i.e., judged alternative 1 as clearly better than alternative 3.
We may just be out of time. If so, we can't relax an error (dynamic of course) in the future -- instead, we have to support String(sym) not throwing, forever (and Symbol.prototype.toString as Claude points out in comment 2).
Details, details! Still worth sweating.
/be
It's now clearly too late to introduce a new Reflect.* API, particularly one that has never been submitted to TC39.
There are many "we could have done this differently" points in the ES6 spec. but the time for design changes has passed.
A Reflect.toString like in Comment 3 seems like a fine thing for someone to champion for ES7, independent of the behavior of String(symbol)