Removal of WeakMap/WeakSet clear

Jason Orendorff jason.orendorff at
Tue Dec 9 16:06:55 PST 2014

On Thu, Dec 4, 2014 at 6:58 AM, David Bruant <bruant.d at> wrote:
> Sometimes you call functions you don't have written and pass arguments to
> them. WeakMaps are new, but APIs will have functions with WeakMaps as
> arguments. I don't see what's crazy. It'd be nice if I don't have to review
> all NPM packages I use to make sure they dont use .clear when I pass a
> weakmap.

...Under what circumstance would you see yourself doing that? Do you
review all the code in NPM packages you use now?

Maybe you look at the source when there's a bug. So is calling
.clear() on an argument that's not supposed to be modified a
particularly likely bug somehow?

> If you don't want to pass the WeakMap directly, you have to create a new
> object "just in case" (cloning or wrapping) which carries its own obvious
> efficiency. Security then comes at the cost of performance while both could
> have been achieved if the same safe-by-default weakmap can be shared.

This is some rhetorical sleight of hand. Logic can't support any
meaning of "safe" here except "safe from clear (and only clear)". But
that's not the only or the most interesting mischief a function with a
reference to a WeakMap can get up to. set() and delete() are much more

> We know ambiant authority is a bad thing, examples are endless in JS.

This much I agree with, and I think it's your best framing of the
question so far, but...

> WeakMap.prototype.clear is ambiant authority.

Here you're just asserting your conclusion. I don't see it as ambient
authority. It can only operate on the object you pass to it.

> I would return the question: can you demonstrate there are no such scenario?

It's hard to prove a negative, but certainly the same technique which
JS programmers already use to avoid having their objects mutated in
unwanted ways also works great with WeakMaps: don't pass around direct
references to them. And I can certainly demonstrate that removing
WeakMap#clear does *not* make it "safe by default" to pass a WeakMap
you care about to bad code.

I think a .freeze() or .frozenCopy() method would be a productive way
of getting the sort of guarantee you're interested in. Immutable data
structures might be even better.


More information about the es-discuss mailing list