let and strict mode

Domenic Denicola domenic at domenicdenicola.com
Sat Nov 17 23:49:14 PST 2012


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: es-discuss-bounces at mozilla.org [mailto:es-discuss-bounces at mozilla.org] 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 <brendan at mozilla.com 
> <mailto:brendan at mozilla.com>> 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
>     es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
>     https://mail.mozilla.org/listinfo/es-discuss
>
>
>
>
> --
> Yehuda Katz
> (ph) 718.877.1325
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
es-discuss at mozilla.org
https://mail.mozilla.org/listinfo/es-discuss




More information about the es-discuss mailing list