V8 prefers to normatively change non-extensible to imply fixed (no private stamping)

[syg]

V8 team's preference is to remove the need for an additional bit for the "no private stamping" behavior, and instead to change non-extensible to imply it. We think this is most natural and aligns best with programmer intuition.

The big question is whether this change is backwards compatible. To that end we've added the use counter V8ExtendingNonExtensibleWithPrivate to see if anyone is actually adding private fields to non-extensible objects today. This is scheduled to hit Chrome stable builds by the end of January, so we won't see truly representative numbers until next year.

In the December 2024 TC39, other delegates and champions were positive on the idea of this change if it's compatible to make.

[Jamesernator]

V8 team's preference is to remove the need for an additional bit for the "no private stamping" behavior, and instead to change non-extensible to imply it.

Doesn't "no private stamping" also apply to window? (which is extensible) (private stamping seemed to work fine in Chrome anyway).

Like one of the motivations for the proxy trap is that it can simulate the builtin behaviour:

The new behavior would follow the existing precedent of the browser global WindowProxy object, so that we could retroactively rationalize it as carrying the fixed trait, and emulations could also be fixed to behave similarly

Without the trap window would remain not emulatable.

[syg]

Without the trap window would remain not emulatable.

Right, this is a consequence of this preference, that window remains exotic. During the last TC39, I clarified with the Agoric folks that they also don't consider explaining window sufficiently motivating by itself. In other words, they can live with it.

[0f-0b]

Does this mean adding a private element to a proxy would now invoke the isExtensible trap?

[erights]

Does this mean adding a private element to a proxy would now invoke the isExtensible trap?

Yes. But without the consolidation, i.e., in the proposal as currently written, adding a private element to a proxy would invoke the is-non-trapping trap. So either way, this would need to trap.