Normative: Refine definition of reachability

[littledan]

This attempts to address various issues with how reachability
is defined:

• If one WeakRef object points to an object, which points to
  another one, the whole subgraph may be collected, as raised in
  https://gist.github.com/jimblandy/0014dc11233d2d40df922af850b0489a

• An initial provisional definition of collectability is given:

  No possible future execution of the program would observably
  reference the object, except through a chain of references which
  includes a [[Target]] field or [[Target]] internal slot.

  This is intended to resolve Interesting impact on other specifications #31 (by concluding that the impact on
  host specifications is minimal, and spec graph reachability does not
  imply liveness) and provide a starting point for Decoupling from spec object graph for nulling out [[Target]] #105

• The wording around 'field or internal slot' is clarified, resolving review: question about when cleanup is allowed #115

[ljharb]

this, i think, still needs the same clarification in lines 116-117? (an alternative would be an abstract operation rather than using prose to describe [[Target]] interaction)

[littledan]

Well, I made sure [[Target]] referred separately to "field" and "internal slot"; isn't it pretty clear what we're talking about given the mention a couple lines earlier? Nothing else uses an internal slot of this name.

[ljharb]

I’m thinking about future uses which might, but might not be intended to be included here. It seems like it wouldn’t hurt to be overly explicit here, even though it’s certainly implied?

[littledan]

I don't think that's how the ES spec is generally written. If an internal slot name is accidentally reused, then, for example, type checks will accidentally pass. The name "[[Target]]" is solidly owned by this proposal, or it will break.

[littledan]

Anyway, fixed it.

[ljharb]

Fair point - the updated version seems good to me, thanks!

[mhofman]

Section 1.5 Modifications to collection type definitions contains similar phrasing that was reworded here.

or if all references to a ECMAScript object are from a [[Target]] field or internal slot

Should that not be updated as well?

[littledan]

@mhofman Ah right, good catch--would you be up for writing a PR to address that?

[mhofman]

I was wondering if that sentence wouldn't become too convoluted if the same change was applied?

If an object that is being used as the key of a WeakMap key/value pair is only reachable by following a chain of references that start within that WeakMap, or if all references to an ECMAScript object are from a [[Target]] field of a FinalizationGroup's [[Cells]] List, or a [[Target]] internal slot of a WeakRef, then that key/value pair is inaccessible and is automatically removed from the WeakMap.

Which also make me wonder why WeakMap/WeakSet entries are not mentioned in the listed conditions here for emptying the slot/field?

Btw, looking at the WeakMap spec, shouldn't the following also be reworded:

For that reason, an ECMAScript implementation must not provide any means to observe a key of a WeakMap that does not require the observer to present the observed key.