Why do JavaScript's WeakMap and WeakSet expose no size property and no way to iterate their contents?

## The rule and the reason `WeakMap` and `WeakSet` have four and three methods respectively — `get`/`set`/`has`/`delete` and `add`/`has`/`delete`. There is no `size`, no `forEach`, no `keys()`, `values()` or `entries()`, no `clear()`, and neither type implements `Symbol.iterator`: ```js const wm = new WeakMap(); wm.size; // undefined wm.clear; // undefined [...wm]; // TypeError: wm is not iterable ``` The reason is that the contents are not under the program's control. An entry survives exactly as long as its key object is reachable; after that, the engine may reclaim it at any moment — during the next minor collection, after a major one, or not at all before the process exits. ## Non-determinism is the core issue Garbage collection timing is deliberately unspecified in ECMAScript. Engines differ (generational, incremental, concurrent), and even a single engine's behaviour depends on allocation pressure, heap limits, and what else the process is doing. Nothing in the language guarantees that an unreachable object is collected by any particular point. Now imagine `weakMap.size` existed: ```js let key = {}; const wm = new WeakMap([[key, 'v']]); key = null; setTimeout(() => console.log(wm.size), 1000); // 0 or 1? ``` The answer would depend on whether a collection happened to run in that second. The same script would print `1` on one engine and `0` on another, or differ between two runs on the same machine. Programs would start depending on it — and any future GC improvement would then be a breaking change. By providing no observation point, the specification keeps collection timing an implementation detail that can never be depended upon, which is precisely what lets engines keep evolving their collectors. ## The information-hiding dimension There is a second motivation. Weak collections are commonly used to hold objects handed in from elsewhere — third-party instances, host objects, values crossing a library boundary. Enumeration would let anyone holding the collection survey those objects, and would let one piece of code learn about objects it never received a reference to. Non-enumerability keeps a WeakMap a pure lookup keyed by something you already possess, which is what makes it usable as a private-state store: without the key object, the entry is unreachable in every sense. ## What you can and cannot build The consequence is practical. You cannot: - count live entries, or report cache occupancy; - iterate to evict, expire, or flush entries in bulk (`clear()` is absent — drop the whole map and allocate a new one instead); - serialise a WeakMap, since `JSON.stringify(new WeakMap())` yields `{}` with no way to recover the contents; - write a test that asserts an entry was collected. You can only ask about a key in hand: ```js const seen = new WeakSet(); function visit(node) { if (seen.has(node)) return; // cycle guard seen.add(node); // ... } ``` If a requirement demands counting or enumeration, that is the signal you need a `Map` or `Set` plus an explicit eviction policy — a size cap, a TTL, or manual `delete` calls at a known lifecycle point — and you take responsibility for the lifetime that the weak structure would otherwise have handled for you. ## The related APIs that do let you observe — carefully ES2021 added `WeakRef` and `FinalizationRegistry`, which get closer to the collector: a `WeakRef` gives a weak reference to a single object whose `deref()` returns either the object or `undefined`, and a `FinalizationRegistry` invokes a callback some time after an object is collected. Even these come with heavy specification warnings: cleanup callbacks may never run, may run in any order, and their timing is not guaranteed, so correctness must never depend on them. They exist for opportunistic cleanup of external resources, not as an escape hatch for enumerating a WeakMap. ## How to say it in an interview The short version is one sentence: the API is small because the contents are non-deterministic, and exposing them would make garbage-collection timing observable. The follow-up that shows depth is naming the alternative — when you genuinely need counting or bulk eviction, you have chosen the wrong structure and should use a strong collection with an explicit lifecycle.