On Apr 23, 2012, at 2:44 PM, Brendan Eich wrote: > Brendan Eich wrote: >> Without arguments runtime semantic shifts, and with |this| lexical, there >> aren't many strict mode changes left IIRC, and they are pretty edgy edge >> cases. > > True enough, but I hang tough on wanting arrows to imply strictness. I may be > wrong but the edge cases cited so far (global variable creation by > assignment, 'with', direct eval injecting 'var' into its dynamic scope) along > with this |this|-boxing one are underwhelming.
IMO, this decision hangs on whether we think strict mode can be thought of as a "cleaning up" that will mostly just catch bugs, resulting in failing faster but otherwise not changing program behavior significantly. POSITION "CLEANUP": If it's just a cleanup, then it makes sense to introduce strict mode in a bunch of places in the language. It'll catch bugs, and for the most part people won't have to think to themselves "is this strict code?" POSITION "MODE": If it's something that is likely to change behavior in meaningful ways other than failing faster, then it's something programmers will have to be mindful of. In that case, having multiple constructs that implicitly introduce strict mode imposes a burden on programmers: they have to know which features are strict and which ones aren't. Every fiber of my being screams MODE. Brendan argues CLEANUP based on the rationale that the non-error semantic changes of strict mode are unlikely edge cases. This is the strongest argument against MODE. I can't prove it wrong, but it's a risky bet. If it turns out to be the case that in practice you need to keep track of whether you're in strict mode, then weak programmers who don't know better will end up with a confusing mess, and strong programmers will prophylactically make sure to put their entire programs in strict mode rather than memorize which subset of syntaxes opt in. Since strong programmers have the option to do that anyway even without multiple implicit opt-ins, why take the risk? Pascal^H^H^H^H^H^H Dave _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
