Even setting aside modern features added after that annual snapshot spec was published (1, 2), class declarations still needed class scope to handle the class binding correctly within the class.
You noted that a class declaration creates a binding for the class name in the scope containing the declaration, whereas a class expression doesn't:
class Example1 { }
console.log(typeof Example1); // "function"
const x = class Example2 { };
console.log(typeof Example2); // "undefined"
While that's true, the inner binding in the class scope is still created, and that's important for resolving the class binding correctly within it. The constructor and methods within the class shouldn't have to rely on that external binding for the class binding, not least because that external binding is mutable:
"use strict";
// Class declaration, creates binding in the current scope
class Example {
method() {
// Note this uses `Example`
return new Example();
}
}
// **BUT**, code can change that binding
const OldExample = Example;
Example = {};
const e1 = new OldExample();
// Should this fail because `Example` has been reassigned, but it's used by `method`?
const e2 = e1.method();
// No, it works just fine
console.log(e2 instanceof OldExample); // true
If method relied on the outer binding of Example, it would be using the wrong thing when it did new Example. But thanks to class scope, it doesn't rely on that binding, it relies on the inner binding for it within the class scope (which is immutable).
As I mentioned, class fields and methods make further use of the class scope, but it was needed even before they were added.
One tricky bit is this sequence you pointed out in a comment on my previous incorrect answer:
- 5.a. Set the running execution context's LexicalEnvironment to classScope.
- 5.b. Let superclassRef be the result of evaluating ClassHeritage.
- 5.c. Set the running execution context's LexicalEnvironment to env.
Why set the running execution context's LexicalEnvironment to classScope just to evaluate ClassHeritage?
Bergi came up with the answer to that, and it's the same answer as for method above: So that the class's binding is properly resolved within ClassHeritage. His wonderfully-succinct example uses a proposal (static methods) that hadn't landed in that spec yet, but it still makes the point:
// shows the class
(class X extends (class Y { static logX() { console.log(X); } }) { }).logX();
That shows a class expression for class X that extends class Y, where class Y is defined within the ClassHeritage syntax production — and refers to X! (Is this a good idea? Probably not. But there may be very edgy edge cases.)
Just for clarity, let's expand that a bit and stick to features in the spec you linked to:
const x = new class X extends (
class Y {
logX() {
console.log(X);
}
}
) {
};
x.logX(); // shows the class
console.log(typeof X); // undefined
So there we are, even class declarations have use for classScope, even before class fields and such were added.
