Early error vs. error on first call to function vs. runtime error

[Brendan Eich]

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