Configurability of @@toStringTag for Built-ins

Brendan Eich brendan at
Tue Dec 16 13:58:49 PST 2014

Allen Wirfs-Brock wrote:
> On Dec 16, 2014, at 10:49 AM, Rick Waldron wrote:
>> Allowing configurability of the value of a built-in object's 
>> @@toStringTag property has the (likely undesirable) side effect of 
>> making calls to unreliable.
>> Illustrated here:
>> Repeated here for the purpose of discussion:
>> Map());
>>   "[object Map]"
>>   Object.defineProperty(Map.prototype, Symbol.toStringTag, { value: 
>> "Fish" });
>>   // ...
>> Map());
>>   "[object Fish]"
>> While this won't break existing code (see: 
>> <>), 
>> there should be consistency across built-ins. I propose we adopt as a 
>> rule that the @@toStringTag for all _built-ins_ is always defined as:
>> { [[Writable]]: false, [[Enumerable]]: false, [[Configurable]]: false }
> The @@toStrngTag mechanism is, by design, unreliable for non-legacy 
> built-ins.  TC39 decided that the legacy use of O.p.toString as a 
> normative type test for built-ins was a practice we wanted support 
> moving forward beyond ES5.

This led to the further complexity in ES6's O.p.toString of prepending 
"~" to a legacy builtin name impostors!

It all hangs together but seems a bit much.

Alternative is to make toStringTag non-configurable for all classes.

> Why do you think there should be consistency across built-ins? What 
> about consistency between built-ins and ES defined classes?

I suspect people (some of 'em ;-) will want consistent high-integrity 


More information about the es-discuss mailing list