Only allow 'unique' and 'well-known' symbols

[acutmore]

Made a start on what the spec text changes could be if registered and well-known symbols were not allowed in WeakMap, WeakSet, WeakRef and FinalizationRegistry

Closes #21

[acutmore]

We create this as a new intrinsic so it can be shared across WeakMap.isValidKey, WeakSet.isValidValue, WeakRef.isValidTarget and FinalizationRegistry.isValidTarget.

[acutmore]

I'm referencing the section rather than the table, because I got a ecmarkup error saying it couldn't find the xref when referencing the table.

[rricard]

It is my understanding that for forward web compatibility we would prefer to actually name the exposed predicate something like isUnforgeable.

The naming here is clear on what we are evaluating: does the thing passed have the necessary property (of being unforgeable) that then happens to be compatible with being a weakmap key or not?

If we end up evolving WeakMap key compatibility later to registered symbols as well for instance, isValidKey would have to be changed, thus breaking web compatibility, while isUnforgeable or similarly named alternatives would not.

[nicolo-ribaudo]

We need to explicitly define .name, otherwise it will probably be missing or "%CanBeHeldWeakly%" (I never read the part of the spec that automatically defines function names). Or you could define it as an "exposed function" directly, similarly to how Array.prototype.values is defined normally and then Array.prototype.@@iterator "copies" it.

[acutmore]

Yes I wasn't sure about this, I do say "The <dfn>%CanBeHeldWeakly%</dfn> intrinsic is an anonymous built-in function object, which I based off how throwTypeError is defined.

The reason I didn't do it as an exposed function was because it has a different name depending on it's home, so not clear which home should win, isValidKey | isValidValue | isValidTarget. There is some precedent for one of them winning though as there is Set.prototype.keys.name === 'values'.

[bathos]

This might be relevant here: tc39/test262#3420.

The %Intl%.[[FallbackSymbol]] symbol is specified to be a new unique symbol associated with each realm. The text here would consider it to be unforgeable, which is theoretically true and will be in some implementations, e.g. Spidermonkey.

V8 however implemented the fallback symbol with the single-identity-across-realms characteristic of a well-known symbol. Though technically incorrect, it seems this may have been a deliberate decision and the discussion about which behavior is desired did not appear conclusive. This proposal might force the issue of getting engines / the Intl spec to agree on the true nature of this abomination.

[ljharb]

Thats something that needs to either be changed in the spec, or, v8 needs to change their implementation, and it should be discussed in plenary regardless of this PR/proposal.

[acutmore]

If I have understood that issue, this is not an issue for this proposal in practice. Because the symbol value itself is not exposed anywhere, so it wouldn't be possible to try and use it in a WeakSet for example. So the spec would say that it is not well-known (cross realm) so can be used in a WeakSet, V8 implement it cross-realm so it is well-known so if they didn't allow it in a WeakSet that would be incorrect, but that incorrect behaviour can't be triggered in any way.

Please do correct anything I have misunderstood.

EDIT: I did misunderstand.

[acutmore]

I re-read the Intl spec and realised I misunderstood, the symbol is exposed directly.

Reflect.ownKeys(
  Intl.DateTimeFormat.call(Object.create(Intl.DateTimeFormat.prototype))
)[0]; // Symbol(IntlLegacyConstructedSymbol)

[bathos]

Yes. Though as you mentioned in another thread, the status of well-knowns as “forgeable” is pretty iffy*. If it’s decided that well-known symbols aren’t considered forgeable, then this outlier-in-practice thing is moot anyway.

* It’s strictly impossible to “prove” either conclusion in all possible scenarios from an ES code runtime POV, so while the spec describes them in terms that consistently support the well-knowns-are-unforgeable conclusion, I understand that this isn’t cut and dry since if a tree falls in the forest...

[acutmore]

It is my understanding that for forward web compatibility we would prefer to actually name the exposed predicate something like isUnforgeable.

Thanks @rricard - good point that this was still being discussed. I've created an issue #24

[acutmore]

Based on the most recently conversations in the Record & Tuple monthly call - I have updated the PR:

• removed the previously included static predicates (e.g. WeakMap.isValidKey)
• widened the CanBeHeldWeakly AO to also return true for well-known symbols by only returning false for symbols that are registered.

[bathos]

also return true for well-known symbols by only returning false for symbols that are registered.

@acutmore I’d thought about this (way too much) and came to the same conclusion, but wasn’t confident about my ability to articulate the case coherently. It’s really cool to see that this is where you’ve landed!