ecma262
ecma262 copied to clipboard
tc39
[Stage 3 Draft] - Symbols as WeakMap keys
⚠ PR acting as preview only ⚠
rendered preview here
This PR represents the Stage 3 specification text for Symbols as WeakMap keys.
The proposed spec has been written as a PR against the full spec due to the high number of small tweaks to descriptions and notes in sections such as liveness.
A separate minimal proposal specification with only the core changes is available at http://tc39.es/proposal-symbols-as-weakmap-keys
I'm getting a 403 error when it tries to upload the preview: https://github.com/tc39/ecma262/runs/6472329978?check_suite_focus=true
Is there something I need to do?
@acutmore i'll take a look at it when i have a moment.
The generated preview seems to have sorted itself out now - thanks anyway!
1 week till plenary. If reviewers could take a look at the latest draft this week that would be great. Thanks! If happy with proposed text then we can check off on the tracking issue https://github.com/tc39/proposal-symbols-as-weakmap-keys/issues/17
cc: @brad4d @ljharb @mhofman @gibson042
Before this lands, I think 402 will need to be updated so the IntlFallbackSymbol is appended to the well-known symbols table (such that the symbol is automatically allowed to be held weakly)
Looks good overall though!
The AO for determining if a symbol can be held weakly is done by exclusion, so IntlFallbackSymbol will be allowed implicitly. It would only be disallowed if an implementation had incorrectly implemented it using Symbol.for, which does not appear to be the case for the implementations I've checked.
https://github.com/v8/v8/blob/5fe0aa3bc79c0a9d3ad546b79211f07105f09585/src/init/heap-symbols.h#L457
https://searchfox.org/mozilla-central/rev/3419858c997f422e3e70020a46baae7f0ec6dacc/js/src/builtin/intl/CommonFunctions.js#735
https://github.com/WebKit/WebKit/blob/84cfeb18efa90b3f67962f66c701f753633c618a/Source/JavaScriptCore/builtins/BuiltinNames.cpp#L44
@acutmore thats a good callout, but a cross-realm, non-registry symbol still belongs in that table, and imo it’s an editorial error in 402 that it does not.
@acutmore thats a good callout, but a cross-realm, non-registry symbol still belongs in that table, and imo it’s an editorial error in 402 that it does not.
I don't believe it's an error. The fallback symbol is not meant to be cross-realm, 402 says explicitly it isn't. However there is no impact[^*] to this proposal since in both cases it could be held weakly.
[^*]: In practice, making Intl unreachable in the current realm would potentially make the symbol to itself become unreachable, which could be observed through WeakRef / FinalizationRegistry if implementations did the work to collect these intrinsics.
To capture @erights's comment during the presentation, we would like to have well-known symbols be normatively described as an invariant along the lines of:
The string properties of the global
%Symbol%that have a value with a symbol type.
Let me know if you want me to open a dedicated issue for this.
To capture @erights's comment during the presentation, we would like to have well-known symbols be normatively described as an invariant along the lines of:
The string properties of the global
%Symbol%that have a value with a symbol type.Let me know if you want me to open a dedicated issue for this.
Opening an issue on the ecma262 repo sounds like the best place to capture that.
This proposal is now stage 4: https://github.com/tc39/proposals/commit/d2a5cf370e4a9dc8b0249ad8a8386cd1280db815
@acutmore: This PR has merge conflicts (from PR #2947, it looks like). If you resolve those, I can take another look.
@michaelficarra and I have chatted about our disagreement of the use of "identity" for the concept of "can be used as a weak target", and we're agreed on stratifying the concept of identity into "specification identity" and "language identity", with "language identity" being the concept that this proposal should use.
This PR should block on https://github.com/tc39/ecma262/pull/3027 which does the stratification.
