Allen Wirfs-Brock (2014-10-01T00:58:42.000Z)
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
> 2) Statically throwing a Syntax Error in assignment expressions, http://people.mozilla.org/~jorendorff/es6-draft.html#sec-assignment-operators-static-semantics-early-errors
see bug https://bugs.ecmascript.org/show_bug.cgi?id=3148 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

Allen


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140930/d16f7e98/attachment.html>
domenic at domenicdenicola.com (2014-10-15T18:40:56.735Z)
On Sep 30, 2014, at 5:09 PM, Shu-yu Guo wrote:

> In the current draft, I see 2 different places where assigning to an immutable binding (`const`) throws an error:

see bug https://bugs.ecmascript.org/show_bug.cgi?id=3148 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