whatwg/streams#932 by @ricea brings up an interesting situation. I'm curious what the champions have to say about this, although I don't anticipate any changes to the weak refs proposal because of it.

The summary is:

• A spec is written so that spec-created object y holds on to a user-provided object x indefinitely
• However, after calling y.close(), y will never use x.
• Thus, it is currently unobservable whether or not an implementation allows x to be GCed before y.

With weak refs, this of course becomes observable. Thus once weak refs are introduced, the spec as-written mandates that x never be GCed before y.

In reaction to this, the spec author should probably change y.close() to null out the internal reference to x explicitly. Then browsers will again be allowed to collect x before y and free up some memory, while still conforming to the spec.

Generalizing, the tricky parts of the situation are:

• Spec authors have to be more aggressive about nulling out internal references than they were before, when such references were unobservable. (Assuming they want to avoid mandating unnecessary memory usage.)
• Implementers now have to be exact in following specs' recommendations on nulling out (or not) an internal reference, since doing so is now observable.
• There are probably many divergences today in memory management strategies between browsers on various APIs of this sort, which may need to be audited now that the strategy is becoming observable.