On Sat, Nov 17, 2012 at 6:06 PM, Brendan Eich <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.


> 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?


> 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;
}


> 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> // 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
> https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss>
>



-- 
Yehuda Katz
(ph) 718.877.1325
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121117/3c87fc28/attachment.html>

On Sat, Nov 17, 2012 at 6:06 PM, Brendan Eich <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.


> 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?


> 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;
}
```

> 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> // 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
> https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss>
>



-- 
Yehuda Katz
(ph) 718.877.1325
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121117/3c87fc28/attachment.html>