Not quite. First, a map from a WeakRef to a value wouldn't do anything useful, since a WeakRef's target dying does not magically blow away the WeakRef itself. Second, you would have no way of getting from an object to its WeakRef(s), so you couldn't do a lookup anyway. But those criticisms are unfair; you're just using loose language to mean a map whose entries hold their keys weakly and values strongly.

But it's not that either. If it were that, and your key died but your map didn't, then the value would still be kept alive. And it doesn't hold both key and value weakly; in that case, you could have both map and key alive and yet the value could die; WeakMaps won't allow that.

It's something subtly different. It's a collection where both the key and map have to be live for the WeakMap entry to keep the value alive. "Weak" in the name is something of a misnomer, in my opinion. Weak normally means "something that can refer to an object without keeping it alive". WeakMap entries are not weak, they are normal strong references that very much keep their values alive -- but only if both the map and key are both alive.

Thanks. That does feel a bit backwards, for the purpose of GF tracking as you can’t store id->obj.

I assume if/when a WeakRef is exposed in the language then a normal map can be used to store id->WeakRef(obj), so no real need them for also having a “mapWithWeakRefValues”?

A WeakMap works with objects as keys. You can do it with objects you don't control, without adding some sort of id field. It can't be fully simulated with a WeakRef.

One common use is to associate extra data with objects, without attaching it to those objects directly. In your map, you add an obj->extradata mapping. Having the target be a WeakRef would just mean you'd lose your extradata while the source obj is still around.