typeof symbol (Was: Sept 19 TC39 Meeting Notes)

Dean Landolt dean at deanlandolt.com
Mon Oct 1 09:23:21 PDT 2012

On Mon, Oct 1, 2012 at 12:00 PM, Rick Waldron <waldron.rick at gmail.com>wrote:

> On Mon, Oct 1, 2012 at 5:26 AM, Andreas Rossberg <rossberg at google.com>wrote:
>> On 30 September 2012 00:08, Brendan Eich <brendan at mozilla.org> wrote:
>> > I think this is too philosophical a discussion to result in a strong
>> reason
>> > to risk "symbol". Just my gut-check. Other TC39ers should weigh in
>> (Andreas
>> > R. especially).
>> Type "symbol" would be my preference, but it is difficult to estimate
>> (for me) whether that involves a risk.
>> However, this clearly is an issue beyond symbols alone. The same
>> problem re-arises whenever we have to add new primitive types in the
>> future. It doesn't seem like a sustainable strategy to fake any new
>> type ever into an object. Perhaps it is less harmful on the long run
>> if we took the chance to clarify _now_ that the set of strings
>> returned by 'typeof' is not fixed, and should not be treated as such?
> +1 for "symbol", after reading through past concerns about adding new
> entries to typeof operator results, I'm not convinced that adding something
> completely new would have any negative side-effects. I'll be the first to
> admit that there are probably edge cases that I may have missed or didn't
> find, but I think the real risk is in piling new things on to existing
> typeof results when they questionably don't belong.
To try and make clear the risk that Brendan's alluding to think of it this
way: how many times have you written code that type-checks and assumes the
range of typeof is fixed? I've written code like this more times than I can

    if (attr == null) // null or undefined
    else if (typeof attr == 'string') // string
    else if (typeof attr == 'number') // number
    else if (typeof attr == 'object') // whoops...
        // handle arrays, objects, dates, regex, etc.

For code that falls through to 'object' it's possible the handler is
sufficiently generic, but changing the range of typeof changes assumptions
and *will* silently break old code, and for the same reason typeof 'null'
was nixed. This is a subtly backward-hostile change that doesn't fix
anything. It just introduces another barrier to es-next migration.

I'm convinced that typeof is a lost cause, but FWIW I believe symbols
themselves give us a way out of this mess.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121001/ed8ffe6a/attachment.html>

More information about the es-discuss mailing list