The static error is problematic. I'm pretty sure that engines that do lazy parsing of functions is not going to report static errors before doing a full parse of the function.
I think we need to either enforce this or remove this restriction. Anything in between will lead to inconsistent behavior between engines. On Tue, Sep 30, 2014 at 8:58 PM, Allen Wirfs-Brock <[email protected]> wrote: > > 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 > > > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > > -- erik
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
