Oliver Hunt (2014-10-01T15:20:15.000Z)
JSC does lazy parsing of nested functions and we have no problem reporting static errors, so i’m not sure what you believe is the problem here.

—Oliver

> On Oct 1, 2014, at 7:09 AM, Erik Arvidsson <erik.arvidsson at gmail.com> wrote:
> 
> 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 <mailto: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 <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 <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 <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 <mailto:es-discuss at mozilla.org>
> https://mail.mozilla.org/listinfo/es-discuss <https://mail.mozilla.org/listinfo/es-discuss>
> 
> 
> 
> 
> -- 
> erik
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20141001/7756dbf2/attachment.html>
domenic at domenicdenicola.com (2014-10-15T18:41:08.793Z)
JSC does lazy parsing of nested functions and we have no problem reporting static errors, so i’m not sure what you believe is the problem here.