`cleanupSome` Is Its Own Proposal Now

In Chapter 19 of the book ("A look ahead...") I cover the WeakRefs proposal, which at the time was Stage 3. As of the July 2020 meeting, WeakRefs is Stage 4 (yay!) — but FinalizationRegistry.prototype.cleanupSome has been split off to its own proposal, currently at Stage 2.

There are a couple of reasons for it, but it's mostly to give people more time to be sure to get cleanupSome right. There were some design changes to it late in WeakRefs' time at Stage 3 which could use some further thought, but moreover there are real questions about when, whether, and where to expose cleanupSome to JavaScript code. From the explainer:

Hesitation: When should cleanupSome be exposed on the Web?

The "long job" case doesn't quite make sense on the "window", the Web's main thread. It makes more sense for background Worker/Worklet threads. So, in browsers, it may make sense to exclude it from the window. There are several other Web Platform APIs which are only exposed in the context of certain global objects and not others, so this would follow a typical idiom.

. Further, Apple has raised concerns about cleanupSome being exposed on the Web at all, due to concerns about whether we want to encourage the "long job" programming style in a context where objects are also being used.

Discussion about where and whether cleanupSome should be exposed in web browsers is ongoing in a WHATWG HTML issue.

Splitting out cleanupSome into a separate proposal would give everyone time to consider its presence in browsers at its own pace.

This almost certainly doesn't affect your use of WeakRefs and finalization registries in JavaScript, because you probably weren't doing "long job"-style programming anyway and didn't need cleanupSome.

Happy Coding!