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>
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
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>


-- 
erik
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20141001/c62c5282/attachment.html>

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.