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

Yehuda Katz wrote:
> On Sat, Nov 17, 2012 at 6:06 PM, Brendan Eich 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:
>
> ```js
> 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