While a |foo| variable is visible through a call to |window.foo|, a |bar| const is always undefined through a call to |window.bar|. This was not the case before the changes introduced for let and const for ES6. Since I see nothing in ES6 that makes this mandatory (this is more a conformance with Chrome), I'm filing this bug. Codepen: http://codepen.io/anon/pen/RaZyMX FWIW, a feature of BlueGriffon was completely horked because of that...
The standard does require this. Otherwise we would never have implemented it, as it horked a ton of stuff for us throughout Firefox. Ask :shu about it sometime. I don't blame you for being unable to find this in the standard, which is practically impenetrable even for people who have lived in there for years. But here's the summary: * ECMA-262 15.1.11 GlobalDeclarationInstantiation <https://tc39.github.io/ecma262/#sec-globaldeclarationinstantiation> specifies how global variable are set up; this happens just before the code of a script starts to run. Step 16.b.i.1 creates `const` bindings by calling CreateImmutableBinding. Step 18.a creates `var` bindings by calling CreateGlobalVarBinding. * CreateGlobalVarBinding is defined in 188.8.131.52.17 <https://tc39.github.io/ecma262/#sec-createglobalvarbinding>. It creates a binding in envRec.[[ObjectRecord]] which entails defining a property on the global object. * CreateImmutableBinding for global environments is defined in 184.108.40.206.3 <https://tc39.github.io/ecma262/#sec-global-environment-records-createimmutablebinding-n-s>. It creates an entry in envRec.[[DeclarativeRecord]], which is the "global lexical scope". No objects are touched. I don't like the global lexical scope. Never did. It's awful. But, we follow the spec. Not sure if this will help, but there is also <https://hacks.mozilla.org/2015/07/es6-in-depth-let-and-const/> which talks about all this nonsense in less technical terms.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → INVALID
Jason, thanks for the detailed info, and sorry then for the spam. If I completely understand that following the spec is needed, please allow me to say that part of the spec is stupid and impossible to understand from a JS author's perspective who's not used to dive into Ecma specs. I find this totally ridiculous and would definitely and strongly support Mozilla if it brings the issue to Ecma (or bring it again, more probably). Anyway, thanks again.
You need to log in before you can comment on or make changes to this bug.