The size of the average JS program is increasing in size faster than machines are getting faster from where I sit. Adding startup overhead should be something TC39 is actively working against.
The "early errors/first run errors" can be caught by other tools as well (linters, in browser developer tools). If said if the checks can be implemented efficiently with near-zero overhead: great! On Thu, Sep 27, 2012 at 8:28 PM, Domenic Denicola < [email protected]> 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. > > 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
