|Issue 327||Remove or simplify support for 'const'|
|Starred by 37 users||Reported by christia...@gmail.com, Apr 24 2009||Back to list|
I think we should consider removing our special handling of 'const' variables and either make them into simple aliases for 'var' or remove support altogether. Const is not universally supported by other implementations and where it is supported has different semantics from ours. There is a fair amount of code in our current implementation and as I understand it using a 'const' variable is more expensive than using a 'var'. Removing support or simplifying 'const' is unlikely to break anything and will simplify our code, in some cases considerably.
Apr 28 2009,
Can you please explain the differences between WebKit/JSC and WebKit/V8 in const handling? That would give us some place to start a meaningful discussion.
Apr 29 2009,
One known difference is that WebKit/JSC does not throw const redeclaration errors. Instead, it just ignores 'var' assignments to 'const' variables. It even allows const variables to be assigned to by a const redeclaration: const x = 27; // x == 27 var x = 28; // x == 27 x = 29; // x == 27 const x = 30; // x == 30
Jan 14 2010,
Feb 19 2010,
The semantics of "const", "let", and nested named function declarations in ES-Harmony has been settled for a long time. All of these bring their name into lexical scope throughout their enclosing block. Both "const" and "let" have a read barrier -- an attempt to read the variable before it has been initialized throws an error. Function names need no such read barrier, since they are initialized on block entry. See http://wiki.ecmascript.org/doku.php? id=harmony:const for how we apply these semantics to global code, where global declarations need to be reflected as properties of the global object. For ES5-nonstrict, I expect each browser will continue to do whatever it does today for each of these cases. For ES5-strict, I think it is important that one either reject these constructs with an early error, or implement the anticipated Harmony semantics. ES5-strict is gated by an opt-in. We do not yet know whether there will be an additional opt-in for Harmony. If not, then it is important that language extensions accepted by ES5-strict not be incompatible with anticipated Harmony semantics.
Feb 19 2010,
Jul 2 2012,
Harmony block scoping has been implemented a while ago, but still coexists with the original 'const' semantics. Once ES6 becomes official, we should look into removing it as obsolete.
Feb 18 2015,
Issue 3898 has been merged into this issue.
Feb 18 2015,
|► Sign in to add a comment|