Throwing errors on mutating immutable bindings

Oliver Hunt oliver at
Wed Oct 1 09:43:09 PDT 2014

> On Oct 1, 2014, at 9:05 AM, Mark S. Miller <erights at> wrote:
> Good point. If we can require all such assignments to be rejected statically, why is a runtime assignment to a const variable even possible? Can't we just assert that this cannot occur?

You mean duplicate assignment? IIRC the problem is code that does

const x;


if (foo)
    const x = bar
    const x = wiffle


Whether this is actually still something that exists - I recall in JSC many years ago we had to allow:
for (......) {
    const x = ...

Even though that is technically duplicate assignment.

But i guess that last case is less relevant as const is now always block scoped isn't it?


> On Wed, Oct 1, 2014 at 8:59 AM, Allen Wirfs-Brock <allen at <mailto:allen at>> wrote:
> On Oct 1, 2014, at 8:39 AM, Mark S. Miller wrote:
> ...
> I was with you until you got to the following point
> >
> > If there is an intervening "with" or sloppy direct eval, then there is not a statically apparent assignment to a const variable. Since this can only occur in sloppy code anyway, it seems more consistent with the rest of sloppy mode for this failed assignment to be silent, rather than dynamically throwing an error.
> >
> const is a new kind of declaration unlike any declaration form that previous existed in ES, so Ii don't think its handling introduces any legacy consistency issues.  If somebody is using const, regard less of mode, they pretty clearly expect assignments to any const bindings to be illegal.  And, I don't think any body wants new silent failure errors, even in sloppy mode.  The most consistent thing is for runtime detected assignments to const bindings to always be noisy errors.  Early where possible, at runtime in the rest of the cases.
> Allen
> -- 
>     Cheers,
>     --MarkM

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list