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

[Brendan Eich]

Allen Wirfs-Brock wrote:
> I see a potential benefit to implementor in the "deferred early error" concept and there are implementation alternatives that would be lost without it.  I see a minor negative impact to developers.  They would need to take an extra pre-deployment action in order to be sure that a ES source file does not violate any  ES static semantic restrictions.  To me this seems like a plausible cost/benefit trade-off.

I don't think this holds up. Modern JS wraps most top level code in

(function () {
   ...
})();

or similar. That makes a bunch of ES6 "static" errors runtime errors.

Anyway, ES5 did what it did. That may be a place to stop adding early 
errors, but agreeing on this point does not automatically include the 
idea of making functions containing tardy static errors into 
invocation-fused explosive devices!

We should consider all the ES6 would-be/maybe-static errors, as decided 
at last week's meeting, and evaluate them one by one. Some may have no 
high analysis overhead.

/be