On 13 April 2013 00:35, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
> there were lots of additional subtle points brought up on the twitter
> threads
>
> Regarding  #1
> This is how it was spec. until the last TC39 meeting.
>
> Some implementers think this will be easiest to implement.

Hm, judging from the most recent replies to the Mozilla bug, the
problems they saw were not specific to symbols (lack of tag bit space
in SM), and seem to have been resolved already.

> 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.

/Andreas

On 13 April 2013 00:35, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
> there were lots of additional subtle points brought up on the twitter
> threads
>
> Regarding  #1
> This is how it was spec. until the last TC39 meeting.
>
> Some implementers think this will be easiest to implement.

Hm, judging from the most recent replies to the Mozilla bug, the
problems they saw were not specific to symbols (lack of tag bit space
in SM), and seem to have been resolved already.

> 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.