-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unnecessary Symbol.iterator
call in subclass default constructor
#827
Comments
I'm reasonably certain it was intentional, and I believe engines are capable of optimizing it when |
@ljharb I meant being able to optimize without the runtime check. |
As the FF engine dev for this very feature, I agree that this was annoying, and I did trip over it in exactly this same way, but I've come around. In ES6, the most obvious and intuitive way to express that function is the way they do it in the spec: constructor(...args) {
super(...args);
} We self-host ours, and that's exactly as it appears in the FF source. The whole idea of default constructors is, "we wrote this the same way you would have, and it's there as a convenience so that you don't have to type it." This is the intuition, and therefore the expectation. Whether it's the easiest for engine devs, it's the easiest for JS devs to understand. A single engine-side runtime check (which JIT authors can move to compile-time, with modern guarding systems) is a small price to pay for the simplicity of that mental model. |
True, but this version of the default constructor could be just non-normative suggestive text instead of normative required text. That would help JS devs understand without requiring that potential side-effect or complicating optimizations. At least, that's how I interpret the point of the OP. |
It could, but that would allow one to observe whether a class had an explicit constructor or not, which would make refactoring it to have one or to not observable as well. Requiring identical semantics for both cases avoids that. |
When I originally wrote the spec. for ClassDefinitionEvaluation I don't believe I considered the possibility that But, I didn't and as has been pointed out in this thread optimizing engines should be able to deal with this. It doesn't seem like something that is worth changing in wither the spec. or implementations unless somebody can show a significant real-world impact of the current spec. |
V8 used to desugar to arguments and @gsathya changed it to desugaring to rest/spread. It felt sort of silly at the time, but at this point, thanks to optimizations by @petermarshall, I believe it's just about as efficient as the old form (though V8 has a quick runtime check IIRC). |
Since it appears my performance concerns are invalid and the bug likely just going to stay, I'm going to go ahead and close this. |
In 14.5.13 Runtime Semantics: ClassDefinitionEvaluation, step 10.a.i, it specifies
constructor(...args) { super(...args) }
as the default constructor. As per 12.3.6.1 Runtime Semantics: ArgumentListEvaluation, this always incurs an observable read and call ofArray.prototype[Symbol.iterator]
. That inhibits the performance optimization of just straight delegating, and it also means at least Babel isn't conforming.I suspect that wasn't intentional?
The text was updated successfully, but these errors were encountered: