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

[Allen Wirfs-Brock]

On Sep 28, 2012, at 9:54 AM, Brendan Eich wrote:

> 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.

Well, my contention is still that  all ES error reporting is done at "runtime". Again, by "static error" I mean one that is detectable by inspection of the source code without any dependency upon runtime state.  Wrapping a function within a otherwise empty anonymous function does not make such errors less "static"

Also, my understanding of what we are discussing would defer reporting to first invocation of the inner-most function containing the error.  In the case of the above module pattern, only early errors at the top level of the anonymous  function would be reported when the anonymous function was called.

> 
> 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!

It isn't clear to me that there is much difference between an invocation-fused explosive function-level and a similarly fused script file or module.  The triggering of each of these normally occurs at some point after some application code has executed to even if we are talking about ES5 "early errors" they are occuring at runtime and may be trigger by some sort of invocation-like action. 

Allen