Same operations for WeakSet

[bakkot]

(See also tc39/proposal-collection-methods#8.)

In particular, I want to be able to do weakSet.union(otherWeakSet) (or something like it) and get a new WeakSet back.

Unfortunately the types are a little confused here because WeakSets are not iterable. As a strawman, we could have versions taking iterables under the same names and also have weak versions taking WeakSets, so you'd have WeakSet.prototype.union(iterable) and WeakSet.prototype.weakUnion(weakSet)

I actually think the WeakSet versions are more important than the Set versions, since they provide functionality which is impossible to write in userland.

I don't think these would cause any issues with making GC observable.

[bakkot]

(A note on "impossible to write in userland" - you can mostly fake it by keeping the underlying WeakSets around, but this only works if you know no one will mutate those sets later: essentially you're forced to have a live view of (e.g.) the union, rather than the union at the time you called .union. And since there's no way of copying a WeakSet, you can't save your own copy which you know no one will touch. Maybe WeakSet.prototype.clone would be worth adding too, come to think...)

[Ginden]

I agree that would be great, but I feel it's outside of scope of this proposal and I don't feel competent to authoritatively speak on matters of WeakSet/WeakMap security.

I asked this question on esdiscuss mailing list, but it didn't receive significant attention. https://esdiscuss.org/topic/cloning-weakset-weakmap

[bakkot]

Sure, no need to expand the scope here. I am going to want to at least make sure whatever approach taken leaves room for a sensible followup adding these operations for WeakSets, but that probably won't be an issue.

I'm happy to do that followup work myself, and having thought more on the matter now feel confident asserting that adding them would not violate any security guarantees at least as I've conceptualized them. Maybe I'll ask in committee to make sure.

[erights]

This is interesting. It should be revisited in the context of tc39/proposal-readonly-collections#2 , where the same implementability questions would arise. The difficultly of implementing in userland might be indicative of a similar implementation burden for implementations using the transposed representation of weak collections.