> From: Andreas Rossberg <rossberg at google.com>
> To: Allen Wirfs-Brock <allen at wirfs-brock.com>
> Cc: "Mark S. Miller" <erights at google.com>, Erik Arvidsson <
erik.arvidsson at gmail.com>, "es-discuss at mozilla.org list" <
es-discuss at mozilla.org>
> Date: Thu, 2 Oct 2014 17:31:15 +0200
> Subject: Re: Throwing errors on mutating immutable bindings
> On 2 October 2014 17:17, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
> > I believe that the module champions have always wanted static
unresolvablse reference rejection to be part of the module semantics.  But
we've never had actual specification for that semantics.
>
> Yes, I had always hoped for a "stricter mode" applied to modules. But
> I don't think that's something that's still possible at this (or a
> later) point. If it had been, then it would have made total sense for
> it to check against const assignments as well, along with a number of
> other things.
>
> > Personally, I think it would be fine for all of these sort of
conditions to be specified as runtime errors and leave it to linters to
find them early and JS implementations to optimize the runtime checks away.

More likely, they will be even more quickly optimized and potentially
inlined as static constants.

>
> Outside modules, with the language being as it is, adding one minor
> new static check definitely does not seem worth the trouble and the
> cost risk.

True, and I don't know of a decently fast ES3/5 parser. ES6 will be even
more complicated, and thus, slower than an equivalence ES3/5 one

>
> /Andreas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20141002/a577c353/attachment.html>

> Yes, I had always hoped for a "stricter mode" applied to modules. But
> I don't think that's something that's still possible at this (or a
> later) point. If it had been, then it would have made total sense for
> it to check against const assignments as well, along with a number of
> other things.

Personally, I think it would be fine for all of these sort of
conditions to be specified as runtime errors and leave it to linters to
find them early and JS implementations to optimize the runtime checks away.

More likely, they will be even more quickly optimized and potentially
inlined as static constants.

> Outside modules, with the language being as it is, adding one minor
> new static check definitely does not seem worth the trouble and the
> cost risk.

True, and I don't know of a decently fast ES3/5 parser. ES6 will be even
more complicated, and thus, slower than an equivalence ES3/5 one