tc39 / proposal-symbols-as-weakmap-keys Goto Github PK

In the SES call today we discussed how a shim of a well-known symbol would have to be implemented to be transparent with ShadowRealm.

There are basically 2 approaches, each with their caveats:

• The shim uses a unique symbol and adds it to the realm's global Symbol. However to ensure that the identity of that symbol is consistent across realms, shims loaded in multiple realms have to coordinate somehow. One way would be to wrap the ShadowRealm constructor.
• The shim uses a registered symbol. It similarly adds it to the realm's global Symbol, but because it uses a registered symbol, no coordination is necessary. However if well-known symbols are allowed as WeakMap key, then the shim needs to wrap WeakMap, and store entries keyed by this fake well-known symbol into a side Map.

Both shims approaches have fidelity issues. In hindsight, I wish well-known symbols were all registered. However if well-known symbols were disallowed as WeakMap keys, it'd allow greater shim fidelity without increased complexity. They could use registered symbols as the synchronization mechanism across realms, with only Symbol.keyFor remaining as fidelity discrepancy for shimmed well-known symbols.

As #21 discussion, symbol as weakmap key have some arguments on registered symbols, both sides seems have good reasons, maybe we should find some tradeoffs which could satisfy both. I think the root cause of the issues is "symbol as weakmap keys" is too general, as I understand, the main use case is sharable identity, which do not need to be such general. Instead, we could introduce a much limited API:

• Symbol.of(object) create the identity symbol for the object
• get Symbol.prototype.object return the object of the identity symbol (return undefined for non-identity symbols)

Usage:

const obj = {}
const sym = Symbol.of(obj)
assert(symbol.object === obj)

Identity symbols (special symbol which ref to the object) would be somewhat like registered symbols (special symbol which ref to the string), so I expect it won't have much troubles to implement.

Note, such API is similar to Object.createSharableIdentity() idea except it use symbol for identity instead of frozen empty object.

Tracking issue for spec reviews for advancement to Stage 3.

From notes: JHD, RGN, BSH, DE MAH

• Richard Gibson @gibson042
• Bradford Smith @brad4d
• Mathieu Hofman @mhofman
• Jordan Harband @ljharb
• (Editor) Michael Ficarra @michaelficarra
• (Editor) Kevin Gibbons @bakkot
• (Editor) Shu-yu Guo @syg

I've just had a discussion with WH to get a clear picture of his objection to allowing symbols created with Symbol.for() as WeakMap keys.

To summarize, This is the use-case that must be disallowed.

1. Symbol.for('name') gets used as a WeakMap key.
2. Later, no references to Symbol.for('name') exist other than the WeakMap key and the (virtual) GlobalSymbolRegistry entry, which don't count. So, both of these are effectively freed.
3. Still later Symbol.for('name') is called again and the result used to attempt lookup in the same WeakMap, finding nothing.

The key misunderstanding many of us have had revolves around the assumption that the GlobalSymbolRegistry entry defined in the spec must keep the Symbol.for() keys alive forever, making them effectively the same as well-known symbols that are stored on global objects. This is incorrect.

In our conversation WH explained it like this.

The VM table you're referring to is spec convenience fiction and an implementation need not implement it that way.

There are many such spec fictions. Consider a program that sits in a tight loop creating objects and not storing them anywhere. Before we had weak maps, we had no notion of object destruction, so per the spec you'd quickly exhaust memory with objects. But a realistic implementation doesn't need to do it that way and can run such a loop indefinitely. Similarly, the VM table is a spec fiction that ensures that when you call Symbol.for twice with the same string, you get the same symbol. Now imagine a program sitting in a tight loop creating consecutive unique strings "0000000000", "0000000001", "0000000002", etc., calling Symbol.for on them, but not storing the symbols anywhere. To preserve the user-visible Symbol.for semantics, an implementation need only to keep track of live symbols, so it's possible for an implementation to run such a loop indefinitely without exhausting memory. That table of all Symbol.for symbols is spec fiction.

So, I believe this proposal & its spec text need to be updated to disallow use of registered symbols as WeakMap keys.

I'm spinning an issue off from @rricard 's comment here: #23 (review)

I remember starting to discuss the different variants of helper functions that could land with this proposal, but I don't recall if we came to a clear answer or not as I failed to take detailed notes.

cc: @ljharb @syg @codehag

Some options for helpers:

A) WeakMap.isValidKey et al

There would also be WeakSet.isValidValid, WeakRef.isValidTarget and FinalizationRegistry.isValidTarget, which would likely all share the same function instance if the logic is the same. This predicate returning true/false would be a direct indication of if the same value would-not/would throw if attempted to be used with an instance of the class.

One issue that has been raised with this helper is that it is likely to 'lock' in the set of valid values; if the only time the logic for this function can change is to encompass new types when they are added to the language, and couldn't change (across versions) for existing types. For example: relaxing the rule to allow 'well-known' symbols in the future. This could impact Record&Tuple, if the initial MVP spec for them says they are not valid WeakMap keys, then this could mean they can never be, as the predicate would need to change its result.

B) Object.isUnforgeable

(Doesn't necessarily need to be on Object). The key idea here, as I understand it, is to de-couple the predicate from if the value can be used in a weak collection. i.e. it can be used as an indicator but does not necessarily perfectly divide values into the two sets of valid/invalid WeakMap keys.

This could potentially allow the set of valid WeakMap keys to change as this predicate itself would always give the same result for a given input across versions. For example isUnforgeable(Symbol.iterator) may always return false**, but registered symbols may throw when used as WeakMap keys in one version but then relaxed in future versions. Or for Record&Tuple, isUnforgeable(Tuple(Symbol)) could always return true, but maybe this does not guarantee that it is also a valid WeakMap key, relaxing this could then be a future separate proposal.

// index.js
delete Array.prototype[Symbol.unscopables];
delete Symbol.prototype.constructor;
delete globalThis.Symbol;
// is `@@unscopables` now unreachable? maybe not as [HasBinding](https://tc39.es/ecma262/multipage/executable-code-and-execution-contexts.html#sec-object-environment-records-hasbinding-n) still references it 
const unscopables = new ShadowRealm().evaluate(`Symbol.unscopables`); // have I re-forged it?

?) Other options?

Z) No new predicate functions

One option is to not introduce new predicates in the spec itself. This would leave userland to create their own predicates and/or use try/catch.

The README is really clear!

Re:

Boxes will not keep objects indefinitely in memory. When a box is not needed anymore, the attached object can be let go.

Does "a box is not needed anymore" mean the same thing as "a box is inaccessible"?

Is this sentence saying the same thing as "when the box is garbage-collected, the attached object can be garbage-collected as well"?

If so, we might want to tweak the semantics so that the boxed object is eligible for collection when the object and its box are inaccessible.

const obj = { hello: "world" };
const box = Box(obj);
window.leakObj = obj; // the box can be collected, but the object itself must live on

I added a spec draft in the main branch. I preserved the original text in the preserved branch, see the diff here.

This proposal allows having a WeakRef to a Symbol, but the definition of liveness used by WeakRefs only talks about sets of objects. It needs to be updated to handle symbols as well.

This proposal has moved to only Symbols as WeakMap Keys and the explainer should be reduced to this content.

This proposal may complement Records and Tuples. However, it's just not a prerequisite: the things you can do in userland are "good enough" to accomplish a lot of things with Records and Tuples, and let the feature "pay for itself". Therefore, while it's good to discuss broader mechanisms for boxing objects, it shouldn't block the Records and Tuples proposal. It's important to explain this relationship in the README.

For example,

• instead of a function, have a string representing an "action" that some other code knows how to execute
• if you have an object containing primitives, spread that into a Record

I think this could meet most use cases, and should be what we open with, so that people understand that the problem here is small and scoped.

As seen in the recent discussions for Realms, this proposal has now become a very useful feature that could be used to share identities through multiple realms. Using Weakmaps with symbol keys would be a first step to config membranes.

This proposed feature goes straight to our usage without increased complexity. Transferring a symbol identity through realms seems like a separate concern. Although, using Records and Tuples for this separate concern still feels overkill as we would need to specify what it means to transfer their structure to set identity references. There is no depreciation for the use cases of R&T, but we'd need to enable Symbols as WeakMap keys as the base for the next proposal-step.

Are all of the following OK?

Box(Box(Box({})));
Box(true);
Box(Symbol());

I deref a weak ref or a pointer; i don't deref a box. I open a box, i take things out of a box, i unbox things.

There's no big fundamental difference between RefCollection, Box and Symbols-as-WeakMap-keys in my mind: they're all about making it so that a primitive type's "identity" can be used to "point" to an object. In the final section of the README, it'd be good to explain this. Maybe reviewers will suggest working somewhere else on the continuum.