On 2/11/2014 11:04 AM, Allen Wirfs-Brock wrote:
>
> I can't find any explicit mention of this in the meeting notes [1] 
> where we decided to make Symbol a primitive type with a wrapper class. 
>  However, I made the appropriate changes to the spec. immediately 
> after that meeting when the discussion was fresh in my mind and I 
> still think that throwing on Symbol(sym) is the right thing to do:
>
> For the other primitive/wrapper types the following conventions apply:
>    new Wrapper(prim)   //always creates a new Wrapper instances 
> wrapping the supplied primitive value
>    Wrapper(prim)            //always returns a primitive value derived 
> by coercing the argument to the appropriate primitive type. Returns 
> prim if same type.
>
> At [1] we made different decisions for symbols and Symbol wrappers :
>   new Symbol(arg)     // always throws, we don't support explicit 
> creation of Symbol wrapper objects
>   Symbol(arg)              // always returns a new, not previously 
> observed, primitive symbol value

One consideration is that it still is possible end up with a Symbol 
wrapper and with the current spec there's no way to unwrap it. The 
argument for having a Symbol wrapper at all was to enabled prototypal 
inheritance, so, in theory, we want to enable people to add methods to 
Symbol.prototype. When non-strict methods on Symbol.prototype are 
called, they'll encounter a wrapped Symbol object that they can't do 
much with since they can never get at the underlying Symbol primitive.

One consideration is that it still is possible end up with a Symbol 
wrapper and with the current spec there's no way to unwrap it. The 
argument for having a Symbol wrapper at all was to enabled prototypal 
inheritance, so, in theory, we want to enable people to add methods to 
Symbol.prototype. When non-strict methods on Symbol.prototype are 
called, they'll encounter a wrapped Symbol object that they can't do 
much with since they can never get at the underlying Symbol primitive.