Toplevel 'let' binding can be left permanently uninitialized after an error

Rick Waldron waldron.rick at gmail.com
Tue Sep 30 10:24:30 PDT 2014


On Tue, Sep 30, 2014 at 1:08 PM, Allen Wirfs-Brock <allen at wirfs-brock.com>
wrote:

>
> On Sep 30, 2014, at 10:00 AM, Rick Waldron wrote:
>
>
> My original response questions were poorly asked. I understand the TDZ
> semantics, but I couldn't reproduce anything meaningful from your original
> example, because I don't have the SpiderMonkey build that includes the let
> updates (presumably Nightly doesn't either, because none of these can be
> reproduced there). I'm trying to understand when/where/why/how the original
> example could happen and what the potential consequences are in terms of
> practical application.
>
>
> Also, note that IE11 apparently implements the ES6 let semantics so it may
> be useful to look at its experience in this regard.
>

As a Mac user, I completely forgot about this. Using Browserstack.com, I
was able to reproduce the original example's behavior by running a script
and then attempting to access or assign to x from the console. The behavior
I observe is exactly what I expect. I'm still unable to provide any further
insight regarding Jason's original comments and practical implications of
reported behavior.

  "That by itself isn't necessarily a problem. I've never written a web
  page where I wanted to recover after a toplevel script threw an
  exception (or timed out)."

I agree with the first assertion for the same reason stated.

Rick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140930/15e19201/attachment.html>


More information about the es-discuss mailing list