On Tue, Dec 4, 2012 at 1:04 PM, Mark S. Miller <erig...@google.com> wrote: > On Tue, Dec 4, 2012 at 10:48 AM, Brendan Eich <bren...@mozilla.org> wrote: >> Kevin Smith wrote: >>> >>> I recommend allowing let declarations only in strict mode. This is the >>> simple, backwards-compatible path. Strict mode only has a bad reputation >>> because, in ES5, it is restrictive-only. There are (almost) no carrots >>> leading users there. >> >> >> Strict mode has a bad rep for two other important causes: >> >> * It forks runtime semantics, which requires careful testing in >> pre-ES5-strict implementations. This has been a real-world problem, multiple >> times. > > I buy this for old code that needs to just keep working, bugs and all, > without human attention. But strict mode can be opted into > incrementally, per program or even per function. For any portion of > code being actively maintained, the non-strict semantics are a hazard. > Admittedly, today with the co-existence of ES3 and ES5, the forking > issue does create an additional problem, because strict code has to > work non-strict as well in old browsers. But pre-ES5 browsers are > finally starting to fade away for real. By the time ES6 rolls out, I > don't expect much ES6 code to be concerned about also running on ES3. > > >> * It deoptimizes, e.g. a strict-mode function must be optimized to copy >> actual parameter values into arguments if it could use the arguments object. > > This one I just don't buy at all. In a strict function f, f.arguments > is poisoned. f's arguments would only need to be reified if f > statically mentions "arguments" or if f has a statically apparent use > of the direct eval operator. For all other cases, no arguments object > need be created, and therefore no copying is needed. > > >>> Leave non-strict as is, and let users opt-in to "let". An excellent >>> carrot. >> >> >> The problem is precisely that users cannot opt into "let" alone by its novel >> syntax. Opting into strict mode may or may not win but it has added costs >> and benefits, and that means let adoption will suffer. > > From what was said at the TC39 meeting, the main "cost" is simply that > strict mode has a bad rep with the community. This bad rep, to the > extent it still exists, is largely superstition. However, the > committee, in fear of this irrationality among the community, is about > to make some bad decisions. This es-discuss list is, perhaps, > adequately representative of the community that if there's an outcry, > not to further cruft up the language for the sake of making ES6 > features available in strict mode at all costs, then perhaps we can
Obviously, that should have been "...available in non-strict mode at all costs" > get the committee to revisit some of those decisions. > > > >> >> 1JS wants new syntax to be its own opt-in. The only issue with making let >> work in non-strict code is the obscure let[i] = j; pattern. If no one >> actually wrote such code (it's possible; public web searches by big >> search-engine companies, or at least one so far, found nothing), then we >> should not risk reduced let adoption by yoking it to the heavier burden of >> strict mode. > > By the time ES6 is a reality, there won't be anything heavy about > strict mode, except the committee's fear of lingering superstition > among developers. > > >> >> /be >> >> _______________________________________________ >> es-discuss mailing list >> es-discuss@mozilla.org >> https://mail.mozilla.org/listinfo/es-discuss > > > > -- > Cheers, > --MarkM -- Cheers, --MarkM _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
