Project: v8 Issues People Development process History Sign in
New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Issue 327 Remove or simplify support for 'const'
Starred by 37 users Reported by, Apr 24 2009 Back to list
Status: Duplicate
Closed: Feb 2015
HW: ----
OS: ----
Priority: 3
Type: FeatureRequest

Sign in to add a comment
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.
Comment 1 by, 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.
Comment 2 by, 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

Comment 4 by, 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
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.
Status: Assigned
Labels: -Priority-Medium Priority-Low Harmony
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.
 Issue 3898  has been merged into this issue.
Mergedinto: 3305
Status: Duplicate
Labels: Priority-3
Sign in to add a comment