Configurability of @@toStringTag for Built-ins

Allen Wirfs-Brock allen at
Tue Dec 16 12:09:49 PST 2014

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. 

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list