typeof symbol (Was: Sept 19 TC39 Meeting Notes)

Rick Waldron waldron.rick at gmail.com
Mon Oct 1 09:41:32 PDT 2012


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... 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. I don't
think this is strong enough to block the possibility of a new typeof result.


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


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



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


Rick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121001/3ff20d02/attachment.html>


More information about the es-discuss mailing list