Unique %Intl%.[[FallbackSymbol]] per-realm

[bathos]

In Chromium currently, %Intl%.[[FallbackSymbol]] behaves like a well-known symbol: it is a single symbol whose identity is shared across realms. It looks like this probably doesn’t have a test currently.

[bathos]

As I researched this further hoping to facilitate triaging the issue, I came across some interesting discussion where many people shared different opinions about the scope of the symbol.

The V8 and Spidermonkey implementations apparently differed in this regard right from the start and it was known at the time. The Spidermonkey behavior is what’s currently specified in ECMA-402, but I couldn’t tell from the old discussion exactly how or why things resolved that way. So I’m now wondering: Is the current spec text contentious? Did V8 choose to retain the secret-well-known symbol behavior deliberately, or was it just a matter of not returning to update the implementation after the behavior was specified as per-realm?

(IIUC littledan, who prob knows the most about this, is likely away, but maybe @caridy or @anba would recall?)

[bathos]

(It seems safe to at least rule out “per realm” being a typo in the spec: it’s explicitly defined as and referenced as the-value-of-a-slot-of-a-specific-%Intl%-object, which is a rather specific thing to do and only makes sense if it’s not well-known.)

[ljharb]

Indeed typically the only per-realm symbols are well-known ones, on Symbol.

[bathos]

Indeed typically the only per-realm symbols are well-known ones, on Symbol.

Hm, am I using the term incorrectly? “Unless otherwise specified, well-known symbols [sic] values are shared by all realms.” When I say V8 has implemented [[FallbackSymbol]] “like a well-known symbol” I mean that it shares a single observable identity across reachable realms (like e.g. Symbol.iterator), yet is not a globally-registered symbol like Symbol.for("something")), and the only other symbols that exhibit this same pattern are the 13 which ECMA-262 defines as well-known.

In Intl right now, [[FallbackSymbol]] is defined as per-realm (the third “kind” of symbol, unforgeable). It gets referenced via the current realm’s %Intl%.[[FallbackSymbol]]. (This is the behavior Spidermonkey implemented.)

“The Intl object has an internal slot, [[FallbackSymbol]], which is a new %Symbol% in the current realm with the [[Description]] "IntlLegacyConstructedSymbol".”

(The above text btw seems kinda underspecified to me? At least, the way it’s “declarative” makes it unclear how it actually integrates w/ InitializeHostDefinedRealm. It’s intelligible, but seems pretty easy to miss.)

[ljharb]

You're using it correctly - what I mean is, I would expect that any Symbol that is not in the registry, and is not a property on Symbol, would not be cross-realm (as the spec says, it seems)

[bathos]

Cool, that was my understanding.

FWIW an interesting twist in the discussion thread where folks debated the symbol’s scope was that it was pointed out that a scoped-to-each-realm symbol would not solve anything that couldn’t have instead been solved using (also realm-scoped) private weak association. In other words, it didn’t need to be a symbol in the first place: same intended effects, all membranes preserved, and yet would have introduced no new property-contract-based way to spawn ersatz NumberFormat instances without constructing or calling the constructor. Altogether, the end result seems kinda surprising to me.

(To be clear I’m not seeking to relitigate whatever was decided there or anything, just very curious to understand where it landed and why. It’s not every day I find a new Extremely Weird thing I never noticed before!)

Edit: actually that comment was about a private cross-realm registry, not per-realm like I thought, but what I said after that is true afaict.

[acutmore]

fyi @bathos I've created a corresponding issue in 402 too: tc39/ecma402#686

[caridy]

@bathos sins from the past. I think your analysis is correct, and maybe just adding a new test here, and perhaps clarifying a little bit better on 402 will be enough. It would have been very bizarre behavior to specify this as well-known symbol considering that Intl is optional anyways.

[anba]

SpiderMonkey has extensive tests for the fallback symbol: https://searchfox.org/mozilla-central/search?q=FallbackSymbol&path=js%2Fsrc%2Ftests%2Fnon262&case=false&regexp=false

[FrankYFTang]

so... can someone make a test262 test to verify the per-realm behavior?
v8 tracking bug https://bugs.chromium.org/p/v8/issues/detail?id=13026

please let me know when the test262 test is merged. Thanks

[FrankYFTang]

Could someone care about this to make a test262 test to verify the per-realm behavior. That will help me to fix the issue in v8.

[FrankYFTang]

@ryzokuken @sffc @romulocintra