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

[Andrea Giammarchi]

It's too late for Symbol, but I agree with Alexander.

Anyway, this is my a summary:

  * `Symbol` is not a class and `new Symbol` throws
  * `Object(Symbol())` is possiboe and it's also an `instanceof Symbol`
  * `Symbol` cannot be implicitly converted to a string so `"" + Symbol()`
throws
  * `String(Symbol())` works though
  * `{[Symbol()]: value}` is by default enumerable, even if kinda born to
be defined on prototypes
  * `for/in` and `for/of` won't show it though ... but ...
  * `Object.assign` will copy them over

As a developer, I would've stick with a basic `String` variant that
inherits `toString` via `Object` prototype and by default is not
enumerable, at least the latter part would've been the only quirk, but a
useful one.

Instead, all the effort put to make it right became quite confusing so
that, from time to time, somebody will ask about `new Symbol` VS `Object`,
about `Object.assign` symbols clashes (iterators and others) and the fact
`JSON` silently ignores them as if these are `undefined` and these are not
even passed to the `replacer` like other enumerable keys.

Yes, there is history, discussions and reasons behind `Symbol` done in this
way, but I bet we can all agree it didn't came out exactly as a "unicorn".

Best Regards


On Tue, Aug 16, 2016 at 12:03 AM, Alexander Jones <alex at weej.com> wrote:

> On 15 August 2016 at 19:20, Allen Wirfs-Brock <allen at wirfs-brock.com>
> wrote:
>
>>
>> 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()`.
>
>
> Honestly, I think this kind of basic type error is something which is so
> trivially catchable at a very early stage when you have even a semblance of
> static analysis. `new Symbol()` should give you an object of class Symbol,
> and `Symbol()` should give you a symbol - and TypeScript even without
> annotations is going to give you a pretty strong warning. IMO it's a bit
> ugly to break the pattern of primitive wrappers being newable for the sake
> of saving programming errors, when the analyzer can do a much more complete
> job anyway.
>
> ```js
> let s1 = String("banana"); // string
> let s2 = new String("banana"); // object
> let o = {banana: 2};
> o[s1];
> o[s2]; // red squiggly: An index expression argument must be of type
> 'string', 'number', 'symbol', or 'any'.
> ```
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20160816/159d3281/attachment.html>