[Vanit]

I don't understand the use case, can someone enlighten me? I've always used them as a caching mechanism for derived / expensive data, and they work perfectly for that as-is. If you want to enumerate them I can't help but think your mental model is wrong and you actually don't want the keys to ever be released from memory.

[davexunit]

I'll try my best to explain.

The use case for Andy here is building backtraces for Scheme compiled to WebAssembly. To print a meaningful backtrace, a Wasm funcref for a compiled Scheme function needs to be mapped to a code origin (file name, line, column). Unfortunately, Wasm can't compare funcrefs, so the host needs to do it. Andy's solution is to have each Scheme Wasm module maintain a WeakMap of funcrefs to code origins. However, this alone is not enough because there may be many Scheme modules that are sharing resources and any given funcref could come from any of the modules. So, the runtime needs to maintain a weak set of all modules so that you can query for the code origin for any funcref and the runtime can search all the modules to find it. A WeakSet would be enough for this task... if it were iterable. To work around this, Andy made an IterableWeakSet which has the drawbacks noted in the blog post.

I also ran into another use case recently while trying to port a library written in a language with iterable weak maps to Wasm with JS providing the weak map support. I'll have to do a very similar, unsatisfying workaround there, too.

[ralusek]

I use WeakMaps all the time. While most cases where I’ve wanted to iterate through a WeakMap are achievable through other means, it usually comes at an inconvenience that usually greatly reduces the utility of using the WeakMap in the first place.

If you’re using a WeakMap to avoid having to do lifecycle-type logic of removing from a map(s) under such and such circumstances, it would often be nice to be able to eschew such lifecycle logic by having items be automatically garbage collected, while still being able to iterate through the items in the map.

[derefr]

How about iterating them to find and flush cache entries with expired TTLs, before they're weak-expired?

[catapart]

This might not be a good use case because I just started doing it and never found a good reason to stop, but I use WeakMaps for keeping references to HTML elements at runtime in library code where I don't want to require a constructor/deconstructor pattern.

Basically, I use them as a reference for DOM elements that my library will do work on, since I can't predict when that DOM element will no longer be a viable reference. And for that - yeah, I can certainly see some benefits to making the thing iterable. Not that I've hit any roadblocks replacing the WeakMap with an array didn't fix. Just that my library array will keep the ref alive until the dev dismisses it. Being able to iterate on WeakMaps would at least give that memory back.