On Oct 11, 2010, at 4:40 PM, David Herman wrote:
> ES3 `catch' is block-scoped. At the last face-to-face, we talked about
> statically disallowing var-declarations from hoisting past let-declarations:
>
> function f() {
> {
> let x = "inner";
> {
> var x = "outer"; // error: redeclaration
> }
> }
> }
>
> I just noticed a case I missed in the discussion, which has actually existed
> since ES3:
>
> function g() {
> try {
> throw "inner";
> } catch (x) {
> var x = "outer";
> }
> }
>
> This is allowed, and it binds a function-scoped variable x, while assigning
> "outer" to the catch-scoped variable x. This is pretty goofy, and almost
> certainly not what the programmer expects. And it's exactly analogous to the
> function f above, which SpiderMonkey currently rejects and we all agreed
> Harmony ought to reject.
>
> It's too late to add this case to ES5's strict mode restrictions, but I
> propose we ought to reject it in Harmony.
Dave caught this glitch in ES5 too late to fix before Ecma submitted the spec
to ISO. We can't change the ES5 spec now. We will fix the spec later, but the
change won't show up in a normative spec for a while. Meanwhile, what
implementations do has more teeth than what a spec says.
Mark Miller makes a good case that implementors should future-proof against
Harmony making this case an error by rejecting it from their ES5 strict
implementations. For Mozilla we plan to do this. It would be good to get
agreement from the rest of the big five, so I'm taking the liberty of mailing
you individually, cc'ing es-discuss (where Mark and your avid fans await ;-).
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
