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
