Why ES6 introduced classes yet `Symbol` not to be used with `new`?

Allen Wirfs-Brock allen at wirfs-brock.com
Mon Aug 15 18:20:45 UTC 2016

> On Aug 15, 2016, at 1:27 AM, Andrea Giammarchi <andrea.giammarchi at gmail.com> wrote:
> FWIW, if `Object(Symbol()) instanceof Symbol` is true, and it is, we can say `Symbol` is just an anomaly in the specs because it acts like other primitive constructors but it throws if used as `new Symbol()`.
> Developers that would've written `new Symbol` are the same that write `new Boolean` or `new Number` and `new String`.
> If these people don't put minimal effort to better learn/use the programming language I wonder why the rest of the entire community should be penalised with "quirks" like `Symbol` is.

The difference is that unlike Number/String/Boolean, there is not a literal syntax for creating Symbol values. For those primitive types that  have a literal representation, it is very rare to ever need to explicitly instantiate a wrapper object via `new` and hence the there is little chance confusing the designation of a primitive value with instantiating a wrapper.

Because Symbol does not have a syntactic literal form, some sort of invocation is required to acquire a new unique primitive Symbol value.  That is where you get the potential for confusion between `Symbol()` and `new Symbol()`.  And minimizing this sort of mistake is not just a matter of needing “better learning”.  Even an experts can have momentary mental slips and type a `new Symbol()` when they really meant `Symbol()`.

In the future, I would expect any new primitive types that have literals to follow the precedent of Number/String/Boolean and any that do not to follow the precedent of Symbol.


More information about the es-discuss mailing list