One reason I can think to disallow this is that it means pure methods can return different results for a given frozen object at different points in its lifetime, which was not previously possible:

function makeSuperReturn(obj) {
  return class {
    constructor() {
      return obj;
    }
  };
}

const o = Object.freeze(Object.create(null));

class C extends makeSuperReturn(o) {
  #brand;
  static isInstance(obj) { // this method is pure!
    try {
      obj.#brand; // n.b. private field access is never side-effecting
      return true;
    } catch({}) {
      return false;
    }
  }
}

C.isInstance(o); // false

new C === o; // true
// note that `new C` is side-effecting and can only be called once without errors (the second time it will attempt to add #brand to o, which already has that field, and so will throw)

C.isInstance(o); // true

I did consider the relationship between field mutation and frozen objects, but I'm not sure I considered field addition in relation to frozen objects.

I believe the guiding intuition here was that if it can already be done with WeakMaps, then it should probably be allowed with private fields.

pure methods can return different results for a given frozen object at different points in its lifetime

That's true today with built-in objects and internal slots though, correct?

A frozen object definitely can return different results based on its implementation, and private fields being a hidden implementation detail should be able to work with Math.random, or like a frozen Map/Set whose internal slot contents can continually be updated.

This is yet another issue that we can only think about well using the WeakMap model. Where is the mutable state? Two objects, Alice and Bob, that share access only to objects that transitively contain no mutable state cannot communicate. OTOH, if they share access to frozen objects that internally contain mutable state, then they may communicate according to the behavior of those objects.

Let's use the term immutable for objects that transitively contain no mutable state, and so are safe to share between subgraphs that should not be able to communicate.

In the WeakMap model of private state, the objects associated with the state may well be immutable. The mutability is in the WeakMap, not in the objects serving as keys into those maps. OTOH, if the object has or inherits methods (whether by class or any other means) that uses those WeakMaps to access this private state, then those WeakMaps are transitively reachable from them and they therefore cannot be immutable.

In the absence of return override and other bizarre escapes from normal class discipline, none of this matters for instances of classes. If the class defines mutable private instance variables, the instances of the class are not immutable under either way of thinking about where the state is. However, in the presence of these bizarre escapes, this accounting does make a difference.

I propose that we reexamine the WeakMap vs Internal slot accounts of private state. Perhaps we should instead repair the supposed "gc semantics" issue that caused us to turn away from WeakMaps. Perhaps just define a WeakMap-like internal spec object with the "gc semantics" we'd like for private state?

Attn @allenwb

For those who weren't there, this issue of how to think about private state (WeakMaps vs private state) came up in an even more dramatic way at the recent tc39 mtg: Private state associated with a proxy is completely disjoint from private state associated with its target. Manipulating either of these states causes no proxy traps. Those thinking of private state as being in the object found this surprising. Those thinking about the state as being in the WeakMap were surprised that others were surprised by this.

Attn @allenwb

@bakkot I like your purity example. In these terms, I would say that the classes returned by makeSuperReturn, if deeply frozen, would be immutable iff the obj they encapsulate is immutable, which is true for your test object o. FWIW, the makeSuperReturn function itself, if deeply frozen, would be immutable.

Not so the class C. It encapsulates the WeakMap used to represent the #brand field. The visible read queries this WeakMap, so no problem. Since all implied accesses to the WeakMap are statically visible and the semantics of WeakMap are known, we could say that a WeakMap that is only read and never written effectively contributes no mutable state. However, C's constructor writes to this WeakMap.

So, o is still immutable. Alice and Bob, sharing access to o and not C, are still not able to communicate. However, if they also share access to C then they can communicate by mutating the mutable state encapsulated within C.

Now that I've written this response, I think your purity example is a truly compelling case that we can only think about clearly using the WeakMap perspective, not the private slot perspective.

Attn @littledan

It is worth stating explicitly, in the explanation of this example, that the class returned by makeSuperReturn(o), if deeply frozen, would be immutable since o is immutable. Alice and Bob, sharing access to o and this class, would still not be able to communicate.

In the current proposal, private state is only associated with an object as part of the constructor evaluation process. I think the proposal can be made stronger such that private state is only associated from within the ordinary [[Construct]] internal method.

I think that the existence of private state (or if you will the association with the conceptual weak maps) should be fixed during construction. I don't think we want to allow additional private state to be added after construction is completed. The only case where freezing could get in the middle of this construction process (in the current proposal) is if a super() invoked base constructor does a freeze on the new instance before returning to a "subclass" (scare quotes in recognition of Reflect.construct) hackery.

Since either way you model it, private state doesn't really involve properties, it is somewhat arbitrary whether or not a freeze in a base constructor prevents a subclass constructor from adding private state. Which way would you want it? I think either alternative is doable. Also, note that is possible to distinguish the invocation of the new.target constructor from the invocation of the base or intermediate superclass constructors. So, it should be possible to define things such that "subclass" association of additional private state is disallowed after completion of the new.target constructor (ie, after returning from the new that created an object. I think that would also be wise.

@bakkot I regret naming the operation in question freeze. Its primary purpose is to make an API surface tamper-proof, so that objects sharing a tamper-proofed object can only interact according to the explicit behavior of the object they share.

I don't think we want to allow additional private state to be added after construction is
completed.

Taking this one statement out of context, given return override, how would you disallow it? How do we know when construction is completed?

How do we know when construction is completed?

("new.target constructor" = the constructor that new was applied to = C in a [[Construct]](C, [... ], C) call)

We know when we are in the new.target constructor and and when we return from it. We also can tell whether the object being returned is implicitly the this value or === to the implicit this value. In that case [[Construct]] could tag such objects as "completed" (ie, no more privates can be added).

A different return over-ride object doesn't get marked completed (but it's distinct construction probably would have already marketed it. A discard incompletely constructed object (neither implicitly or explicitly returned from its new.target constructor) is not marked as completed and probably garbage. In any cases it isn't following normal construction protocol, so it isn't clear why we care that it is left incomplete.

Finally, I still think it would be best if we make all private associations (including subclass privates) in the base class constructor. I think the complications in doing so (and the edge cases it exposes) are smaller/simpler than what falls out of incremental association. (and as a bonus, we get back the possibility of bump allocation of a complete object).

I still think it would be best if we make all private associations (including subclass privates) in the base class constructor.

Doesn't this reopen the fields vs slots question that had originally caused these two proposals to be unmerged? We were able to merge only when you agreed with the semantics implied by the WeakMap perspective. We then agreed to rephrase it in terms of slots but keeping the observable consequences that followed from weakmaps. With me (and others?) realizing that the only way to clearly explain some of the tricky issues is to retain the weakmap phrasing, and you wanting to return to the observational properties of the original slots proposal, has our merge failed? Should we re-split the proposals, so that their differences return to their previous clarity?

@allenwb, I think private fields should mirror public properties as closely as possible for questions like when they are added to the object, when initializers are executed, and whether they get added to objects provided by return-override. Otherwise the semantics are completely confused. And I think the current execution model is the correct one for public fields.

(I also think it should be possible to add private fields to frozen objects, both when the super constructor freezes this and when the super constructor returns a new frozen object, which does break symmetry with public properties. But I'm fine with that.)

As @zenparsing and @ljharb point out, frozen objects already have mutable private slots, so I think it is ok to preserve the current language. As an example of mutable private slots:

let p, resolve;
p = new Promise(r => resolve = r);
// p.[[PromiseState]] === 'pending'
Object.freeze(p);
resolve();
// p.[[PromiseState]] === 'resolved'

I think a NOTE in the spec explaining the WeakMap formalism is the best way to resolve this, which would allow us to keep current spec language and semantics but make it more obvious how private fields interact with e.g. freeze.

Yes, the current proposal deliberately allows private state to be defined on frozen objects, for the WeakMap analogy, including adding new private slots. I will have to look into the Construct semantics possibility further.

I can't see how we can make Construct semantics work, but OTOH I added non-normative text to the spec referring to the WeakMap analogy. Hopefully this should make it clearer why private state can be added and manipulated on frozen objects. (Internal slots are another way to look at it--those can be manipulated on frozen objects.)

We've concluded that private fields have "WeakMaps semantics" and can be added to frozen objects.