Throwing errors on mutating immutable bindings
erik.arvidsson at gmail.com
Wed Oct 1 07:09:08 PDT 2014
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 <allen at wirfs-brock.com>
> 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 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
> 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
> es-discuss mailing list
> es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss