<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 15 August 2016 at 19:20, Allen Wirfs-Brock <span dir="ltr"><<a href="mailto:allen@wirfs-brock.com" target="_blank">allen@wirfs-brock.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
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()`.</blockquote><div><br></div><div>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.</div><div><br></div><div>```js</div><div><div>let s1 = String("banana"); // string</div><div>let s2 = new String("banana"); // object</div><div>let o = {banana: 2};</div><div>o[s1];</div><div>o[s2]; // red squiggly: An index expression argument must be of type 'string', 'number', 'symbol', or 'any'.</div><div>```</div></div></div></div></div>