Brendan Eich wrote:
We have not discussed error-on-first-call in this thread at all!
This needs a separate thread. The idea from last week's TC39 meeting was
to have not only
* Early error, thrown before any code in the Program (grammar goal
symbol) containing the error, required by specific language in Clause 16.
* Runtime error, all the other kinds.
and now
* Error on first call to a function, where the function contains what
would be an early error but for the supposed cost of early error analysis.
The last case is really just a runtime error: a function with what
should be a static error becomes a booby trap: if your tests happen to
miss calling it, you'll feel ok, but a user who tickles the uncovered
path will get a runtime error.
TC39 heard from some implementors who wanted to avoid more early error
requirements in ES6, or at least any that require analysis, e.g.
reaching definitions.
That's fair as input to the committee, but implementation concerns are
not the only ones we weigh. And we were far from agreed on adding the
"Error on first call" category.
The example you imply here would be
function f(a, b = c, a = d) {
}
and the duplicate formal a would be illegal because of the novel
default-parameter syntax.
Making f into a proximity-fused bomb does not see either good or
necessary. The analysis requires to notice duplicate formals is trivial,
and as I keep pointing out, ES5 already requires it:
function g(a, a) {
"use strict";
}
This must be an early error per ES5 clause 16.
Given the ES5-strict sunk cost, there's no added implementation tax
beyond the logic conjoining duplicate detection with novel-syntax
detection, which is trivial.
It'd be good to hear from Luke on this.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
