Le 13 avr. 2013 à 09:56, Andreas Rossberg <rossberg at google.com> a écrit :

> On 13 April 2013 00:35, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
>> <snip>
>> 
>> Regarding #3
>> 
>> The biggest footgun is if
>>  new Symbol()
>> creates a Symbol wrapper.  However,
>>  new Symbol()
>> returning a primitive values would be unlike anything we currently have in
>> the language
> 
> I agree, it has to be the former. But what footgun are you seeing
> there? Any attempt to use a wrapper as a key throws under the
> agreed-upon semantics, so I don't see the issue.

As a JS programmer, I will be very tempted to write `new Symbol` to get a new symbol. The issue is that you get an error in a different line of code from where the problem lies, and you have to be fond of the subtle distinction between value and object wrapper (which is a feature we never use in our daily coding) to understand what is happening without external help. 

In order to mitigate the problem without introducing inconsistency with legacy constructors of primitives, I propose to poison the Symbol constructor, so that it throws a TypeError with a useful message when called as a constructor. The error message would include (inter alia) something like "To obtain a new symbol, use `Symbol()`."

People who have a really good reason for wanting a wrapper Symbol object should already know that you can obtain one with `Object(Symbol())`. 

—Claude

> 
> /Andreas
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

Le 13 avr. 2013 ? 09:56, Andreas Rossberg <rossberg at google.com> a ?crit :

> On 13 April 2013 00:35, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
>>
>> Regarding #3
>> 
>> The biggest footgun is if `new Symbol()`
>> creates a Symbol wrapper.  However, `new Symbol()`
>> returning a primitive values would be unlike anything we currently have in
>> the language
> 
> I agree, it has to be the former. But what footgun are you seeing
> there? Any attempt to use a wrapper as a key throws under the
> agreed-upon semantics, so I don't see the issue.

As a JS programmer, I will be very tempted to write `new Symbol` to get a new symbol. The issue is that you get an error in a different line of code from where the problem lies, and you have to be fond of the subtle distinction between value and object wrapper (which is a feature we never use in our daily coding) to understand what is happening without external help. 

In order to mitigate the problem without introducing inconsistency with legacy constructors of primitives, I propose to poison the `Symbol` constructor, so that it throws a `TypeError` with a useful message when called as a constructor. The error message would include (inter alia) something like "To obtain a new symbol, use `Symbol()`."

People who have a really good reason for wanting a wrapper `Symbol` object should already know that you can obtain one with `Object(Symbol())`.