Throwing errors on mutating immutable bindings

Allen Wirfs-Brock allen at
Tue Sep 30 17:58:42 PDT 2014

On Sep 30, 2014, at 5:09 PM, Shu-yu Guo wrote:

> Hi all,
> In the current draft, I see 2 different places where assigning to an immutable binding ('const') throws an error:
> 1) Dynamically throwing a TypeError in SetMutableBinding,
> 2) Statically throwing a Syntax Error in assignment expressions,
see bug the "can" in that sentence isn't meant to be interpreted as "best effort" but instead more along the lines of "it is provable".

We need to refine that language, but the test is approximately that there are no with blocks inside the scope of the const declaration and surrounding the reference to the const. binding

> 1) throws only in strict mode code, while 2) throws regardless. 2) is also best effort; seems to be implementation-dependent what "can statically determine" entails.
> Is the intention that assigning to consts silently nops if the implementation cannot determine the assignment to be to a const statically, in non-strict code, but implementations *should* make a best effort to report such cases eagerly, regardless of strictness? Seems kind of odd to me; perhaps I am misreading?

1) looks like a bug to me.  I pretty sure it was never the intent for assignments to const binding to silently fail in non-strict code. The current semantics of SetMutableBinding is a carry over from ES5 where immutable bindings were only used (I have to double check this) for FunctionExpression function name bindings. The legacy of ES3 (hence non-strict ES5) was to did not throw on assignments to such function name bindings.

I'll probably have to do some extra special casing to preserve the ES3/5 semantics for assignment to function names and make the throw unconditional to other immutable bindings


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list