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, http://people.mozilla.org/~jorendorff/es6-draft.html#sec-declarative-environment-records-setmutablebinding-n-v-s
...
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?
>response
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
Allen
however, after thinking about this for a while I think the current spec'ed behavior is probably necessary in order to not break existing code that uses various pre-ES6 standard forms of const declarations.
also see https://github.com/tc39/tc39-notes/blob/master/es6/2014-11/nov-18.md#43-assignment-to-a-const-static-error
fixed in rev29 editor's draft
fixed in rev29