Class private fields can't be used with extends null

[ExE-Boss]

📝 See tc39/ecma262#1036 and tc39/ecma262#1321.

---

With public fields, you can at least do:

class Foo extends null {
	foo;
	constructor(foo) {
		return Object.create(new.target.prototype, {
			foo: {
				configurable: true,
				enumerable: true,
				writable: true,
				value: foo,
			},
		});
	}
}

But with private fields, you can’t use the Object.create work‑around.

---

It’d be so much easier if:

class Foo extends null {};
new Foo;

and

class Foo extends null {
	constructor() {}
};
new Foo;

didn’t throw.

---

That would allow class fields to also be used with extends null:

class Foo extends null {
	#foo;
	constructor(foo) {
		this.#foo = foo;
	}
}
new Foo;

[ljharb]

This is a result of classes themselves not properly supporting null. You can, however, extend a class that extends null and uses your workaround.

[rdking]

What's the glitch in the null support?

[ExE-Boss]

The issue is that a constructor that extends null ends up with its [[ConstructorKind]] internal slot set to derived instead of base, which results in the implicit constructor being constructor(...args) { super(...args); } and the this binding being uninitialized instead of OrdinaryCreateFromConstructor(newTarget, "%Object.prototype%").

This is being fixed in issue tc39/ecma262#1036 (PR: tc39/ecma262#1321).

[rdking]

I get it. Now just out of curiosity, why was class designed that way? It seems like it would've made things cleaner for there to never be a [[ConstructorKind]], for all actions to happen as if "derived" were the only kind, for the class base to always be either Object, null, or user specified, and for super() to be an internal function that automatically handles the special case of a null base. So why split the situation into something that requires 2 different constructor types?

[rdking]

Just thought about it. That's questions better targeted on es-discuss...

[littledan]

Yeah, classes extending null is sort of generally broken, unfortunately. See tc39/ecma262#1321 for some further discussion. Closing this issue, as it's not about class fields.