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

[Kris Siegel]

Interesting.

Because, to be consistent with Number/String/Boolean you would expect `new
> Symbol()` to create a  Symbol wrapper object.


Currently Symbol is the only primitive that can't be converted to a string
through the use of the + operator, so why the consistency in one place and
the lack thereof in another? I understand there isn't really a meaningful
representation of Symbol() as a string but I didn't see any particular
reason in my cursory look at the past notes for it to throw an exception so
I've been curious.

But we anticipated that if `new Symbol` was allowed many devs (who lacked
> an understanding of the difference between primitive values and wrapper
> objects for primitive values) would code `new Symbol()` with the
> expectation that they were creating a Symbol value. This would be a silent
> bug so we disallowed `new Symbol()`.


Forgive me for the ignorance but what kind of bug would this introduce?
Since Symbol() is already an oddball compared to all other built-in objects
and primitives would it have been so bad to simply make `new Symbol()`
equate to `Symbol()`? I'm not sure you'll get developers to understand the
difference between primitives and wrapper objects (still haven't found one
yet who understands this in my inner-circle of JS devs that I know at
least).


On Sun, Aug 14, 2016 at 9:18 PM, Domenic Denicola <d at domenic.me> wrote:

> I believe, but am not sure, that we also decided we would follow that
> pattern for any future primitive types, since in general constructing
> wrapper objects is a bad idea. (I want to say that wrapper objects
> themselves are a bad idea, but I think the conclusion was more subtle than
> that... they are an important part of the semantics, it's just unfortunate
> that they're so easy to create.)
>
> If some enterprising person wants to dig through the meeting notes, there
> might be some hints there...
>
> > From: Allen Wirfs-Brock [mailto:allen at wirfs-brock.com]
> >
> > Because, to be consistent with Number/String/Boolean you would expect
> `new Symbol()` to create a  Symbol wrapper object.  But we anticipated that
> if `new Symbol` was allowed many devs (who lacked an understanding of the
> difference between primitive values and wrapper objects for primitive
> values) would code `new Symbol()` with the  expectation that they were
> creating a Symbol value. This would be a silent bug so we disallowed `new
> Symbol()`.
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20160814/b2b42108/attachment.html>