Personally, the fact that modules opt in to strict mode completely obviates the problem for me. I anticipate this to be the case for most "non-beginner" ES programmers as well, since they are largely using either a CommonJS-like or an AMD module system, and as part of an ES6 migration would then move to ES6 modules. (Note: perspective bias probably in play here.) Even for future-beginners, i.e. beginners in a post-ES6 world, they will presumably be taught to always use modules.
Of course it remains important to specify exactly which course you guys want to take, but I just wanted to provide some perspective that the exact solution for non-strict code is probably, hopefully, not terribly impactful. I guess this could be an argument toward (1)? -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Brendan Eich Sent: Sunday, November 18, 2012 04:25 To: Yehuda Katz Cc: es-discuss Subject: Re: let and strict mode Yehuda Katz wrote: > On Sat, Nov 17, 2012 at 6:06 PM, Brendan Eich <[email protected] > <mailto:[email protected]>> wrote: > > Dave Herman proposed as part of 1JS that module imply strict mode, > so let is reserved in module. So that helps. > > For let outside of modules, we could contextually parse let at > start of statement if followed by an identifier or a { that starts > an object pattern. We could even allow LineTerminator after let, > and perhaps should try to get away with that. > > But if we allow LineTerminator and risk some backward incompat, > can we up the ante by allowing [ after let? > > Who knows, but we have some choices: > > 1. 'let' only in strict code including modules per 1JS as > originally proposed. > > > This would essentially be sending the message: "get your ES5 house in > order before trying to use ES6 binding forms". I'm not sure how I feel > about this, but getting people to clean up code invalid in ES5 strict > mode is a nice carrot. Yes, this is the simplest and safest course. > 2. 'let' followed by identifier or { but not LineTerminator. > > 3. 'let' followed by identifier or { with LineTerminator and other > space allowed in between. > > 4. 'let' followed by identifier, {, or [ and LineTerminator in > between is ok. > > > Trying to identify `let` usage by known ES6 syntax could be future > hostile, by limiting our ability to extend the BindingList grammar. It > would essentially restrict us from adding any prefixes to > BindingIdentifier that could be ambiguous in ES5. I'm not fully enough > aware of all of the historical proposals to know whether any of these > could become issues in the future: let ?foo, let ^foo, let &foo. Maybe > there's something I'm missing and this category of problem could not > arise? Good points, especially ? as prefix, although we seemed to agree that patterns are irrefutable (match undefined), so a refutable option might prefer prefix-! to imply a "cut" (throw in a binding form; try next pattern in a multi-match construct). > 5. We could also allow 'let' per (4) in functions not in modules > that do not "use strict" but do use new ES6 syntax in their heads, > e.g. destructuring parameters, default parameters, rest > parameters. Those head features could arguably opt into 'let' > syntax but not strict mode. > > > I'd be worried that it would confusingly break refactored code: > > function isPermitted(user) { > var permissions = [].slice.call(arguments, 1), > let = authorize(permissions); > > if (!let) { return false; } > else return permissions; > } > > // to > > function isPermitted(user, ...permissions) { > var let = authorize(permissions); > > if (!let) { return false; } > else return permissions; > } Yes, this is a downside. I don't favor (5) on this account. New syntax is its own opt-in but using a rest parameter should not opt the whole body into a different piece of new syntax. /be > > > Comments? > > /be > > Kevin Smith wrote: > > > var let = function() {}; > let(); > > > If let is a contextual keyword (in non-strict mode of course), > then we can look ahead to the token after `let` to validate > it. An open paren cannot follow a let *keyword*, so therefore > it must be an identifier. > > var let = { it: "be" }; > let.it <http://let.it> <http://let.it> // be > > > > Same logic applies. A dot cannot follow a let keyword so we > parse it as an identifier. > > On the other hand, an open square bracket *can* follow a let > keyword (by array destructuring), so we have a potential > ambiguity there. > > - Kevin > > _______________________________________________ > es-discuss mailing list > [email protected] <mailto:[email protected]> > https://mail.mozilla.org/listinfo/es-discuss > > > > > -- > Yehuda Katz > (ph) 718.877.1325 > _______________________________________________ > 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
