Closed Bug 855665 Opened 10 years ago Closed 8 years ago

Enable let without version=1.7+

Categories

(Core :: JavaScript Engine, defect)

Product:
Core
Component:
JavaScript Engine
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: evilpie, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: meta) 

We probably should implement the new yield parsing for that first.
In a next step we should see if we can remove all the version number crap.
Blocks: 1JS
yield works now, but let still doesn't. CCing Wingo who was the one to fix yield. Wanna give 'let' the same love?
I don't have time to do this unfortunately.  Also it's quite a tricksy project :)  Best of luck to the hacker that takes this bug!
Summary: Enable let and yield without version=1.8 → Enable let without version=1.8
Honestly I have no idea how it's expected to enable |let| for all JS.  Every time it's been tried -- by us once or twice, by JSC once, maybe others -- it's foundered on web-compatibility rocks.  Unless we want to switch and actively evangelize sites not to use |let| as a variable name -- and our track record of evangelizing rather than backing out worthy changes is abysmal -- I think this is doomed.
Has someone raised this with TC39? AFAIK it's in the spec.

I think it's limited to only strict mode, but I don't know if that makes a difference compatibility-wise.
I'm similarly pessimistic.  In any case it is possible to enable let within strict mode, though.
Actually, given that 'let' is *already* a reserved word in gecko in strict mode, I see no problems with enabling it there?

Am I missing something?
TC39 should be aware.  Our people there are aware of such experiments, olliej there is as well.  Not to be too jaundiced about it, but I think they're in the let's-pretend-we-can-la-la-la-and-maybe-things-will-change-eventually mindset.  Which, honestly, isn't entirely crazy, just enough that I would bet against it.

There are perhaps no reasons we couldn't enable let in strict mode, except that TC39 doesn't really like strict mode much, and in their (also perhaps jaundiced) view, basically nobody uses it, and thus it doesn't really matter what's done there.  But others who have paid closer attention to TC39 recently may have more informed views of the question.
I'd be happy to use let if it was available … We just have a chicken-egg problem ATM, and I'd very much appreciate if let were available in strict mode at least (that allows developers to get comfortable with it, even if it is not available in non-strict mode for now!). As most ES6 syntax triggers strict mode, the "user base" for let will grow soon enough. If and when let will be available for non-strict mode, can be decided at later point (though it's definitely preferable to not fragment the web more). 

And maybe, within a year or two, the legacy-let-problem will be solved by itself, so we can enable let in non-strict without breaking legacy code.
Is our let the same let as TC39 let?
According to MDN, it's not block-local yet (which TC39 let is).
I am pretty sure it is block local. Test this:

{
 let a = 5;
}
alert(a)

The major difference that I know of is bug 589199.
Also the (In reply to :Ms2ger from comment #9)
> Is our let the same let as TC39 let?

AFAIK, no.  ES6 let has a temporal dead zone.  In SM:

js> (() => { let f = () => b, a = f(), b = 1; return [a, b]; })()  
[(void 0), 1]

whereas the reference to b before assignment should raise an error.
(In reply to Jeff Walden [:Waldo] (remove +bmo to email) from comment #3)
> Honestly I have no idea how it's expected to enable |let| for all JS.  Every
> time it's been tried -- by us once or twice, by JSC once, maybe others --
> it's foundered on web-compatibility rocks.

Could the JS parser distinguish between |let| the keyword and a variable name, depending on context?

  let let = ":)";


(In reply to Andy Wingo [:wingo] from comment #12)
> Also the (In reply to :Ms2ger from comment #9)
> > Is our let the same let as TC39 let?
> 
> AFAIK, no.  ES6 let has a temporal dead zone.  In SM:

Is there a bug to implement ES6 let's temporal dead zone? I can't find one.
Depends on: 589199
OS: Linux → All
Hardware: x86_64 → All
(In reply to Chris Peterson (:cpeterson) from comment #13)
> Could the JS parser distinguish between |let| the keyword and a variable
> name, depending on context?
> 
>   let let = ":)";

It really should be raised on TC39, rather than introducing yet another SM quirk.
(In reply to comment #13)
> Could the JS parser distinguish between |let| the keyword and a variable name,
> depending on context?
> 
>   let let = ":)";

No.

  let[x] = [42];

Destructuring declaration of |x|?  Or assignment to the property named by |p| on the global property |let|?

Of course, you could try to sub-distinguish to exclude that case somehow...or something.  But it seems to me pretty dangerous or so to try to be too fine-grained about it, just in terms of language aesthetics and web developer sanit and all that.
(In reply to Jeff Walden [:Waldo] (remove +bmo to email) from comment #7)
> TC39 should be aware.  Our people there are aware of such experiments,
> olliej there is as well.  Not to be too jaundiced about it, but I think
> they're in the
> let's-pretend-we-can-la-la-la-and-maybe-things-will-change-eventually
> mindset.  Which, honestly, isn't entirely crazy, just enough that I would
> bet against it.

Here are is the discussion for reference: https://github.com/rwaldron/tc39-notes/blob/master/es6/2012-11/nov-29.md#the-syntax-of-let


> 
> There are perhaps no reasons we couldn't enable let in strict mode, except
> that TC39 doesn't really like strict mode much, 

If you have been keeping up with the notes[0] that I've published since May 2012, you'd know this isn't true at all.

> and in their (also perhaps
> jaundiced) view, basically nobody uses it, and thus it doesn't really matter
> what's done there.  

Again, this is false. The committee believes that strict mode will eventually be the only mode. New scoped binding forms are all strict by default now (eg. class body and module body).

> But others who have paid closer attention to TC39
> recently may have more informed views of the question.

[0]https://github.com/rwaldron/tc39-notes
OK the notes say `let` for strict mode, no `let` for non-strict. Can somebody change the summary then, please?
(In reply to Rick Waldron [:rwaldron][:rick][:rick waldron] from comment #16)
> 
> Here are is the discussion for reference:
> https://github.com/rwaldron/tc39-notes/blob/master/es6/2012-11/nov-29.md#the-
> syntax-of-let

Rick: Do your 2012-11 meeting notes in comment 16 reflect the committee's current thinking about let? If so, then we can implement let in strict mode and non-strict mode (with single token lookahead).

TL;DR:

  LH: A search of indexed web reveals 3 uses of var let.

  ...

  Conclusion/Resolution

  In non-strict code: let, with single token lookahead (where the single token is either an Identifier,
  "[", or "{" ), at the start of a statement is a let declaration. (Accepted breaking change)
Keywords: feature
(In reply to Florian Bender from comment #17)
> OK the notes say `let` for strict mode, no `let` for non-strict. Can
> somebody change the summary then, please?


I suspect you misread the notes. `let` in strict code is a non-issue, because `let` is reserved in strict code. The committee agreed to move forward with `let` in non-strict code, b/w a lookahead: https://github.com/rwaldron/tc39-notes/blob/master/es6/2012-11/nov-29.md#conclusionresolution-6




(In reply to Chris Peterson (:cpeterson) from comment #18)
> (In reply to Rick Waldron [:rwaldron][:rick][:rick waldron] from comment #16)
> > 
> > Here are is the discussion for reference:
> > https://github.com/rwaldron/tc39-notes/blob/master/es6/2012-11/nov-29.md#the-
> > syntax-of-let
> 
> Rick: Do your 2012-11 meeting notes in comment 16 reflect the committee's
> current thinking about let? If so, then we can implement let in strict mode
> and non-strict mode (with single token lookahead).
> 
> TL;DR:
> 
>   LH: A search of indexed web reveals 3 uses of var let.
> 
>   ...
> 
>   Conclusion/Resolution
> 
>   In non-strict code: let, with single token lookahead (where the single
> token is either an Identifier,
>   "[", or "{" ), at the start of a statement is a let declaration. (Accepted
> breaking change)


Yes, this remains the current consensus and is not likely to change before January 1, 2014. I'm going to follow up with Allen re: spec draft coverage.
In rev20 of ES6 Draft:

13.4 Expression Statement
Syntax

ExpressionStatement[yield] :
  [lookahead ∉ {{, function, class, let [ }] Expression[in, ?yield] ;


I'm reopening the spec bug because `let {` is missing
(In reply to Rick Waldron [:rwaldron] from comment #19)
> (In reply to Florian Bender from comment #17)
> > OK the notes say `let` for strict mode, no `let` for non-strict. Can
> > somebody change the summary then, please?
> 
> 
> I suspect you misread the notes. `let` in strict code is a non-issue,
> because `let` is reserved in strict code. The committee agreed to move
> forward with `let` in non-strict code, b/w a lookahead:
> https://github.com/rwaldron/tc39-notes/blob/master/es6/2012-11/nov-29.
> md#conclusionresolution-6

I'm sorry, my comment was a bit unclear. AFAIU, `let` for strict mode can be implemented right away, while it is okay to delay `let` for non-strict mode. That's what I thought this bug should be about now (thus not covering `let` for non-strict, and do that in a follow up).

Did I get that correctly?
Depends on: 932513
Depends on: 932517
I filed blocking bug 932513 ("Enable let without version=1.8 in strict mode") and bug 932517 ("Enable let without version=1.8 in non-strict mode"). Separate bugs for separate issues. :)
Keywords: feature → meta
(In reply to Florian Bender from comment #21)
> (In reply to Rick Waldron [:rwaldron] from comment #19)
> > (In reply to Florian Bender from comment #17)
> > > OK the notes say `let` for strict mode, no `let` for non-strict. Can
> > > somebody change the summary then, please?
> > 
> > 
> > I suspect you misread the notes. `let` in strict code is a non-issue,
> > because `let` is reserved in strict code. The committee agreed to move
> > forward with `let` in non-strict code, b/w a lookahead:
> > https://github.com/rwaldron/tc39-notes/blob/master/es6/2012-11/nov-29.
> > md#conclusionresolution-6
> 
> I'm sorry, my comment was a bit unclear. AFAIU, `let` for strict mode can be
> implemented right away, while it is okay to delay `let` for non-strict mode.
> That's what I thought this bug should be about now (thus not covering `let`
> for non-strict, and do that in a follow up).
> 
> Did I get that correctly?

I can't really comment on the implementation strategy for ES6 features in SM, but I trust that those of you working directly on such things know the best path forward there. I'm just trying to provide clarity on behalf of the committee.

A more important concern for me is that `let` and `const` are implemented correctly and IIRC, the impl in version=1.8 is not aligned with ES6's temporal deadzone semantics.
`const` is even worse in that regard, as it is not even block scoped.
Assignee: general → nobody
let is currently available in javascript;version=1.7 and 1.8.
Summary: Enable let without version=1.8 → Enable let without version=1.7+
No longer blocks: 1121323
No longer depends on: 589199
Blocks: 1002741
Fixed by bug 932517.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.