typeof symbol (Was: Sept 19 TC39 Meeting Notes)
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
>>> > to risk "symbol". Just my gut-check. Other TC39ers should weigh in
>>> > 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.
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
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss