tc39 / proposal-record-tuple

ECMAScript proposal for the Record and Tuple value types. | Stage 2: it will change!
https://tc39.es/proposal-record-tuple/
2.48k stars 62 forks source link

Looking to confirm: CanBeHeldWeakly remains false even if rec/tup includes unforgeable symbols? #384

Closed bathos closed 1 year ago

bathos commented 1 year ago

The proposal currently doesn’t expand CanBeHeldWeakly with any new behavior for e.g. #[ Symbol("can-be-held-weakly") ]. I wouldn’t necessarily expect it to, but because that AO / the ability to weakly hold identity-bearing symbols is itself a recent addition, I wanted to confirm the intention is to not make the identity semantics of identity-bearing constituents “bubble up” in the same way that SV/SVZ semantics do.

(I think being able to use #[ symbolRepresentingObject, andAnother, andOneMore, andMaybeSomethingForgeableToo ] as a composite weak key would actually have pretty major utility — but I’m guessing if it were to ever happened, it’d be in a future proposal.)

acutmore commented 1 year ago

Hi @bathos yes that's correct. It was mostly discussed in relation to when the proposal had the notion of Box as a way to reference an object from a R/T here https://github.com/tc39/proposal-record-tuple/issues/233, with https://github.com/tc39/proposal-symbols-as-weakmap-keys being the replacement for how to 'reference' an object from the R/T the same conversation still applies - with 'box' replaced with 'unique symbol'.

As mentioned in that thread, the capability exists without direct support. So it would be a connivence, rather than providing a new capability. To do this in userland, the R/T is walked to extract all the weakly holdable symbols and then a trie of WeakMaps is created to link this entire set of symbols to the R/T which is placed in a regular Map associated to the final WeakMap in the chain.

bathos commented 1 year ago

Thanks! I didn’t know what to make of the Box discussions when I was looking for prior info about this, so the context about how the notion ended up evolving is helpful.

I realized it wouldn’t constitute a new fundamental capability — I’ve done what were roughly “tuples w/ object members” in userland before myself, though I doubt as elegantly or efficiently as someone else might have. Even so I think composite key utils/syntax/whatever would be pretty valuable language-level features. (That’s all unrelated to this proposal of course, though).