Reconsidering Reflect[Symbol.toStringTag]

[domenic]

#495 indicates that it is intentional to not give Reflect a Symbol.toStringTag value, making it intentionally inconsistent with the older namespaces Math and JSON. The implication was then that all future namespace objects should not have such toStringTags.

However, since that time Atomics was added, and given a toStringTag. At this point it seems like Reflect is the odd one out.

It'd be good to get a conclusion here especially to inform the web platform. Currently the specification for web platform namespaces does not indicate they should have any toStringTag. But, browsers are inconsistent: of the three namespaces WebAssembly, console, and CSS, there seems to be some agreement that WebAssembly gets a toStringTag, but the others do not. We're trying to straighten this out, but can't figure out which direction to go in, because the ES spec itself is inconsistent.

My recommendation is that everything gain a Symbol.toStringTag, including Reflect, and that we align the web platform namespaces in the same way. I.e. favor consistency over the simplicity arguments from #495. However, I'm fine with the opposite conclusion, where Math, JSON, and Atomics become legacy exceptions; we should just state it clearly (perhaps with non-normative notes in the toStringTag subsections for each of these objects).

[domenic]

I see that Intl is another namespace to add to this consideration. Currently it has no toStringTag.

[shvaikalesh]

I am more inclined towards

However, I'm fine with the opposite conclusion, where Math, JSON, and Atomics become legacy exceptions;

due to simplicity arguments in #495 (comment). Inheriting from %Object.prototype%, extensibility, and lack of @@toStringTag together make namespace objects idiomatic, aligning them with user-land code authored before CommonJS.

Atomics[@@toStringTag] breaks harmony era consistency though, making me wonder if we could remove it since only V8 shipped Atomics?

[ljharb]

cc @syg re Atomics question

[annevk]

Note that Firefox will soon have Atomics as well (though initially without means to make globalThis.SharedArrayBuffer defined and postMessage() for SharedArrayBuffer non-throwing). And that branches in a week so I suspect initially it'll be whatever we have on Nightly at the moment.

cc @evilpie @codehag

[evilpie]

I think having @@toStringTag is nice for debugging and general consistency.

On the other hand it seems like in DOM/HTML land "namespace" objects like window.CSS don't get a @@toStringTag property either.

[ljharb]

If we decide to go with "maximal toStringTagging for debuggability", then should import.meta gain a tag as well?

[littledan]

I'm +1 on adding toStringTag to new namespaces going forward.

[domenic]

Would someone be willing to drive this to consensus within TC39? (I think I can speak for web specs and say that we'll be fine to follow any precedent.)

[ljharb]

I’ll prepare a needs consensus PR and add it to the next meeting’s agenda.

[domenic]

Thanks @ljharb! Perhaps you, or one of the 402 editors, could do the same for Intl?

[anba]

Already happened in tc39/ecma402#430

[domenic]

Hmm, I don't see anything for Intl itself, just for sub-objects of it...

[anba]

Oh, right. Looks like that one should be added, too.

[bakkot]

@domenic Consensus from TC39 is that we are in favor of namespace objects having Symbol.toStringTag, and will do so for Reflect and Intl.