typeof symbol (Was: Sept 19 TC39 Meeting Notes)

[Brendan Eich]

Rick Waldron wrote:
> Offline discussion with Dave that immediately identified a 
> deal-breaker: if typeof symbol were "string", it would break ===.
>
> === for strings is based on their contents
> === for objects is based on their identity

That's true but I think it has not to do with ===. It's because symbols 
must not be forgeable by spelling out any "contents" or "value" that can 
== or === another symbol's contents/value.

The invariant that applies:

    (typeof x == typeof y && x == y) <=>  (x === y).

This would hold even if typeof returned "string" for a symbol, so long 
as that symbol was == and === only itself.

It obviously also works if typeof returns "object" for a symbol, as in 
the current proposal.

In the sense that "abc" === "ab" + "c" then of course Dave's right. You 
can't do any such thing with a symbol. But so long as unforgeability is 
upheld, this issue is not about === (or ==). It's about typeof returning 
"string" for a symbol, a bad idea.

The lack of String.prototype delegation as if by auto-wrapping is a 
second deal-killer.

Between "object" and a new typeof result, "symbol", the safer course is 
"object".

For value objects such as int64 and uint64, I've come to believe that 
the invariant above conjoined with

   (0L == 0UL) === true

being the desirable == but not === behavior requires typeof 0L => 
"int64" and typeof 0UL => "uint64.

Value objects have content-based identity, but they're objects. Symbols 
could be viewed as objects and identity and typeof all work "for free".

To resolve Andreas's concern about cost of object, we could say that 
Symbols are frozen and empty. That would be enough to optimize as hard 
as possible.

/be