GC considerations and user-visible changes in state

[rakuco]

At the Devices and Sensors WG F2F at TPAC, w3c/wake-lock#128 tracks the problem of locks that currently cannot be released depending on how they are created.

The issue boils down to the fact that fixing that potentially involves describing some actions that must be performed when a lock is garbage collected, but that would also trigger changes to user-visible state (a WakeLocks active member would change). We had a similar problem in w3c/sensors#372, but for sensors there's no changes in object state that is visible to users.

We're wondering if there's a guideline for this kind of issue.

[domenic]

Isn't https://w3ctag.github.io/design-principles/#js-gc the guidance?

[littledan]

I'm glad the design principles document that best practice. I agree that depending on GC should be avoided. However, I think that, given that WeakRefs is at has cross-browser consensus and is at Stage 2, we should revisit the strength of the guidance (see #100). WeakRefs leave open a much bigger space for observation of GC than the linked issue. And this leak seems intolerably bad.

[torgo]

Discussed on breakout 30-march-2020 and we think this has been addressed already in the document.