Question about utility of .isWellKnownSymbol

[ljharb]

Today in plenary, @syg indicated that he and the v8 team are no longer convinced of the utility of this predicate (.isRegisteredSymbol remains important for WeakMap keys). An additional category of concern was the additional difficulty this will create in polyfilling well-known Symbols.

My positions include the following:

• "polyfillability" has always been explicitly rejected as a design constraint for language proposals
• well-known Symbols can't be faithfully polyfilled regardless, because they're cross-realm (and some of them require syntactic support), and the only polyfillability boundary that matters imo is "100%" or "not 100%"
• it's easier to patch/wrap this predicate than to build it from scratch
• having a way to determine whether a Symbol is well-known is valuable, because they're cross-realm, and the engine pays them special attention for protocols
• A predicate is the most convenient/ergonomic way to determine this

Use cases I have include:

• debugging/inspection output
• identifying cross-realm values (well-known and registered symbols being the only ones in the language)

More concrete use cases from others would be appreciated to make a stronger case for this predicate.

[concavelenz]

Can you be specific at to a protocol where you believe it would be useful to determine whether it is a well known symbol, without known which symbol you interested in? For example, I can see the value is knowing whether something is "Symbol.iterator" but see little value in knowing "this might be 'Symbol.iterator', 'Symbol.replace', 'Symbol.unscopables' ,etc"

If polyfills may replace "isWellKnownSymbol" due to polyfilling a new "well known symbol" that would defeat its purpose for "symbols that can cross realm". Would a different tool/name be more appropriate?

Not to nitpic, but I don't believe it is true to say that these symbols are the only cross realm values: numbers, strings, booleans, etc are cross realm values. Regardless, once you do identify these cross realm symbols, what would you do with the information?

[ljharb]

@concavelenz I think the space for polyfilling a well-known Symbol is irrelevant because it can't be done faithfully.

Let me rephrase, using terminology in the spec: well-known and registered Symbols are the only cross-realm values with identity.

One thing one might do is reject these values. Another is to branch, and preserve the identity of these values since it matters on both sides. These values can also be passed into and out of Shadow Realms, and their identity will match the existing values on the "other side". There's lots of contexts where this information is valuable.

[concavelenz]

Can you be more specific? I failed to see what use case you have in mind that you would treat any differently. Yes, you could branch but for what purpose?

…

On Mon, May 15, 2023, 10:36 AM Jordan Harband ***@***.***> wrote: @concavelenz <https://github.com/concavelenz> I think the space for polyfilling a well-known Symbol is irrelevant because it can't be done faithfully. Let me rephrase, using terminology in the spec: well-known and registered Symbols are the only cross-realm values with identity. One thing one might do is reject these values. Another is to branch, and preserve the identity of these values since it matters on both sides. These values can also be passed into and out of Shadow Realms, and their identity will match the existing values on the "other side". There's lots of contexts where this information is valuable. — Reply to this email directly, view it on GitHub <#12 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJQGKWUFYWIW4UVTFZUNWLXGJSRRANCNFSM6AAAAAAYCPLV6I> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[syg]

+1 to @concavelenz, is there a concrete example that showcases a use case? What kind of code has different behavior depending on if a Symbol is well-known, perhaps with ShadowRealms since you brought that up?

I can imagine high-fidelity polyfills that just surface that information to whoever uses that polyfill, but that's not compelling in itself because concrete uses of that polyfill needs to be demonstrated.

[mhofman]

What a faithful polyfill means in the presence of ShadowRealm is interesting, but somewhat orthogonal to well-known symbols. I'm of the opinion that we will need a mechanism to initialize "child" realms, which would help polyfill and other first run changes to the environment apply to newly created realms.

What's particularly interesting for ShadowRealms here is that symbols are allowed as-is through the callable boundary, so a faithful polyfill would have to be careful to initialize the shimmed well-known symbol to the same value. I can think of 2 ways faithful polyfill may accomplish this: rely on registered symbols, or passing the shimmed value through the callable boundary when initializing the realm. Given that well-known symbols are allowed as WeakMap keys, the former approach would require patching a ton of unrelated intrinsics like WeakMap and WeakSet (see discussion at tc39/proposal-symbols-as-weakmap-keys#27). That means well-known symbols would likely be implemented as unique symbols in faithful polyfills.

Back to the use cases, in one of our libraries, we do treat well-known symbols as special, however it's a bit of a generalization of handling specific protocols: our marshalling layer recognizes well-known symbols and serializes them for transmission over the wire. The intent is to be able to use symbol protocols the same as method calls over a serialized connection. For that specific use case, it would be simpler and more future proof for that library to use a predicate that checks whether a given symbol is well-known. We currently build the predicate ourselves by enumerating the symbol values of the Symbol constructor.

[concavelenz]

It seems like you already have a solution and this method provides no capability. It would be no more reliable in the face of polyfills - which may or may not patch this method as whether or not you want to distinguish polyfills from platform provided symbols is unclear.

[ljharb]

@concavelenz this method provides a source of truth that doesn't require a dynamic approach, that's still valuable. Polyfills aren't relevant imo.

[concavelenz]

In what way are they a source of truth that is different than values already on Symbol? Either you are trying to distinguish between values that have been added (i.e. polyfills) in which cases polyfill providers should not modify the method or if you aren't then the polyfill providers should modify the method.

The use case is so specific and vague (it isn't clear to me that the distinction is necessary) that the existing approach seems more than sufficient.

[ljharb]

Polyfill providers would of course have to modify the method; that’s always in scope for polyfills.

[syg]

Thanks for the use case, @mhofman. The existing userland implementation you linked seems fine to me? That is, it does not seem harder to build and maintain this thing from scratch than putting the ecosystem in a state where there are wrappers patching this predicate depending on the preferences of how faithful a polyfill author wants to be.

[ljharb]

tbh I'm not sure why we're talking about polyfills at all. All builtins are subject to patching by polyfills, and it's fine - just like polyfillability isn't something that impacts proposal progress, i wouldn't expect "somebody might polyfill it" as something that would impact it either?

[syg]

We're talking about polyfills because we're weighing upsides and downsides.

The upside is not requiring a userland implementation for a pretty specialized use case that's not part of the language (unlike WeakMap keys). The userland implementation @mhofman linked doesn't seem that bad to me.

The downside is more work for polyfill and library authors not via a simple patch but chained wrapping. Not all builtins are subject to that.

Polyfills aren't usually in consideration for proposal progress because usually there's sufficient signal for wanting it or not wanting it without considering polyfills. From my POV that signal isn't here for this method: the potential upside isn't compelling enough on its own, but it's also not a huge burden to add, so it seems fair to bring in other considerations like polyfilling that can better inform an opinion here.