I'm generally against error on first call -- in the general case if you're able to determine a function should fail on first execution you can determine that it could fail during parsing and semantic analysis.
--Oliver On Sep 27, 2012, at 9:01 PM, Brendan Eich <[email protected]> wrote: > Domenic Denicola wrote: >> As a user, not implementer, I really want early errors. Perf costs of >> startup are negligible especially long-term. By the time ES6 is in browsers >> computers and phones should be faster by enough of a factor to mitigate any >> costs, whereas omitting early errors hurts developers indefinitely into the >> future. > > Totally agree! > > Others on TC39 made this point too. We're not near consensus, unfortunately. > > /be > > >> >> On Sep 28, 2012, at 4:02, "Brendan Eich"<[email protected]> wrote: >> >>> 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 >>> >> >> _______________________________________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss >> > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
