typeof symbol (Was: Sept 19 TC39 Meeting Notes)

Dean Landolt dean at deanlandolt.com
Mon Oct 1 12:17:11 PDT 2012

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

> On Mon, Oct 1, 2012 at 9:23 AM, Dean Landolt <dean at deanlandolt.com> wrote:
>> 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 count:
>>     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.
> The example you gave wouldn't be "symbol aware" anywhere else either...

Sorry, I somehow clipped off my else clause that demonstrated the problem
(assumed function). I also missed 'boolean'.

> but let's say that this is part of some library code that accepts
> arguments from user code and a symbol is passed in - none of those
> conditions would be met (if typeof "symbol") and therefore nothing would
> happen.

This is where we disagree. Something bad will almost certainly happen if
your "else" clause isn't "object". I bet an awful lot of code in the wild
assumes the range of typeof to be invariant. I'm not claiming the range of
typeof is codified as a language invariant (I haven't checked the spec),
just that there is sure to be code in the wild that assumes this and will
be tripped up by a contravariant change. That's why I referred to it as
backward hostile, not backward-incompatible.

> I don't think this is strong enough to block the possibility of a new
> typeof result.

Fair enough. But is there any value in a new typeof result? I surely can't
see any. It's broken beyond repair -- I don't see the use in breaking more
code trying to salvage it :P

>> 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.
> Adding a new result that accompanies a new language feature is not the
> same as changing something with 17 years worth of extant code.

If you consider the range of typeof to be a language invariant it's the
same class of problem.

>> This is a subtly backward-hostile change that doesn't fix anything. It
>> just introduces another barrier to es-next migration.
> It's only "backwards-hostile" if user code intentionally creates hostile
> execution paths. Any comparison using "symbol" simply won't evaluate to
> true in older implementations... but then older implementations won't have
> symbols anyway.
Any fallthrough that assumes complete coverage of the typeof range is a
hostile path. I believe these are common enough to be a concern. The fact
that IE already extends the range of typeof probably could mean less cause
for concern, but this is still a real problem. I know I wrote an awful lot
of code assuming the range of typeof to be a language invariant -- I doubt
I'm alone.

>> I'm convinced that typeof is a lost cause, but FWIW I believe symbols
>> themselves give us a way out of this mess.
> I don't actually see what symbols themselves will do to be so heroic

I should have been more clear -- symbols give us protocols. For instance,
it'll get a whole lot easier to test for "array-like" when all we care
about is whether something is iterable. And how do we tell that? The
language gives us this perfect, intensional key. This general pattern can
be extended for custom protocols. I think that's pretty heroic :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121001/1c4270a0/attachment.html>

More information about the es-discuss mailing list