Map, Set, WeakMap, WeakSet

[conartist6]

It seems to me that this proposal creates a second kind of immutability in addition to the first kind of immutability that the language has with frozen objects.

Currently ArrayBuffer is one of a handful of cases where Object.freeze() does not actually prevent data structures from changing. The others (that I can think of) are Map, Set, WeakMap, and WeakSet.

I'm a bit unsettled that this proposal is on track to create a second definition of immutability that but without resolving the issues that would then require a third definition of immutability to be developed.

All this means that this proposal actively harms any future proposal to develop deep immutability, and that irks me since deep immutability is one of the most impactful wins that you can get out of having native support for immutability

[mhofman]

this proposal is on track to create a second definition of immutability

Actually this helps bring TypedArray instances in line with the existing immutability concepts. Currently a TypedArray can only ever be frozen if it has a 0 length. Since the indexed properties of TypedArray backed by an immutable ArrayBuffer are non-writable, this proposal makes it possible to freeze a TypedArray instance.

A frozen object never guaranteed that its internal state is immutable. Map/Set etc. are already different from TypedArrays because accessing elements is done through methods, not through property access. If your program wants to rely on freezing as an immutability contract, it also needs to check the shape of the properties of the object, and verify that no accessors are involved (this is actually what we do in Endo.js).

[conartist6]

It would just be nice if there was one definition of [[isImmutable]] internally and it controlled immutability for all core data structures. If the native implementation of Map.prototype.set respected that [[isImmutable]] internal field then no userspace extensions could change the data at that point. Map.prototype.set.call(Object.freeze(new Map()), key, value) would fail.

Yes, anytime you invoke a getter you're introducing the possibility of state creeping in, but that doesn't really worry me as much as it worries me that it isn't possible to use regular non-extended maps in a structure of primitives if you also need freezing.

[ljharb]

Having that fail would be web-incompatible.

[conartist6]

I know. But to some extent that doesn't matter to me in thinking of how this should work. Once we know how it should work, then we can figure out how to get from where we are now to where we want to be

[mhofman]

I think having immutable versions of Map/Set is worth considering for a future proposal, but I don't believe the approach taken for ArrayBuffer is applicable nor relevant. It may very well be that we end up with an .immutable property on those instances, or something else entirely.

However freezing a Map/Set instance should never IMO cause its internal state to become immutable, for the same reason freezing an instance of a class wouldn't affect its private fields or data associated through WeakMap. This is the same reason freezing an ArrayBuffer doesn't make it immutable.

[bakkot]

There is a very old proposal for readonly Map/Set. It does not make sense to have immutable versions of WeakMap and WeakSet, although the above proposal also suggests having readonly views of mutable collections, which would work for WeakMap and WeakSet.

[conartist6]

My intent in creating this issue was to propose that we at least rule out "something else entirely"