<br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Nov 17, 2012 at 6:06 PM, Brendan Eich <span dir="ltr"><<a href="mailto:brendan@mozilla.com" target="_blank">brendan@mozilla.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Dave Herman proposed as part of 1JS that module imply strict mode, so let is reserved in module. So that helps.<br>


<br>
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.<br>


<br>
But if we allow LineTerminator and risk some backward incompat, can we up the ante by allowing [ after let?<br>
<br>
Who knows, but we have some choices:<br>
<br>
1. 'let' only in strict code including modules per 1JS as originally proposed.<br></blockquote><div><br></div><div>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.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">2. 'let' followed by identifier or { but not LineTerminator.<br>


<br>
3. 'let' followed by identifier or { with LineTerminator and other space allowed in between.<br>
<br>
4. 'let' followed by identifier, {,  or [ and LineTerminator in between is ok.<br></blockquote><div><br></div><div>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?</div>

<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">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.<br>

</blockquote><div><br></div><div>I'd be worried that it would confusingly break refactored code:</div><div><br></div><div><font face="courier new, monospace">function isPermitted(user) {</font></div><div><font face="courier new, monospace">  var permissions = [].slice.call(arguments, 1),</font></div>

<div><font face="courier new, monospace">      let = authorize(permissions);</font></div><div><font face="courier new, monospace"><br></font></div><div><font face="courier new, monospace">  if (!let) { return false; }</font></div>

<div><font face="courier new, monospace">  else return permissions;</font></div><div><font face="courier new, monospace">}</font></div><div><font face="courier new, monospace"><br></font></div><div><font face="courier new, monospace">// to</font></div>

<div><font face="courier new, monospace"><br></font></div><div><font face="courier new, monospace">function isPermitted(user, ...permissions) {</font></div><div><font face="courier new, monospace">  var let = </font><span style="font-family:'courier new',monospace">authorize(permissions);</span></div>

<div><span style="font-family:'courier new',monospace"><br></span></div><div><div><font face="courier new, monospace">  if (!let) { return false; }</font></div><div><font face="courier new, monospace">  else return permissions;</font></div>

</div><div><font face="courier new, monospace">}</font></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">


<br>
Comments?<br>
<br>
/be<br>
<br>
Kevin Smith wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">
<br>
        var let = function() {};<br>
        let();<br>
<br>
<br>
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.<br>
<br>
       var let = { it: "be" };<br></div>
    <a href="http://let.it" target="_blank">let.it</a> <<a href="http://let.it" target="_blank">http://let.it</a>> // be<div class="im"><br>
<br>
<br>
Same logic applies.  A dot cannot follow a let keyword so we parse it as an identifier.<br>
<br>
On the other hand, an open square bracket *can* follow a let keyword (by array destructuring), so we have a potential ambiguity there.<br>
<br>
- Kevin<br>
</div></blockquote><div class=""><div class="h5">
______________________________<u></u>_________________<br>
es-discuss mailing list<br>
<a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" target="_blank">https://mail.mozilla.org/<u></u>listinfo/es-discuss</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Yehuda Katz<br>(ph) 718.877.1325<br>
</div>