Block scoping and redeclarations

Brendan Eich brendan at
Wed Aug 24 10:28:38 PDT 2011

On Aug 24, 2011, at 9:43 AM, Allen Wirfs-Brock wrote:

> On Aug 24, 2011, at 2:01 AM, Andreas Rossberg wrote:
>> On 23 August 2011 19:14, Allen Wirfs-Brock <allen at> wrote:
>> Oh, but that description does not cover Dave's exact example, which actually was
>> { { let x; { var x } } }
>> Here, the var is hoisted across the let's scope, but doesn't end up in
>> the same scope. And we clearly want to rule that out, too. But then,
>> you also want to properly distinguish this case from, say
> This is essentially the same as the hosting a var out of a catch clause where the var and catch parameter have the same name.
> I tried to get that defined as an error for ES5 and it didn't fly because of backwards compat. concerns. I suspect we would come to the same conclusion this time.

Wasn't the concern theoretical? We have more time now to shake the trees. If we find web content with "... catch (e) {... var e...}" then we should think hard (my migration tax argument cuts all ways). But I've never seen any such code. Indeed try/catch is rare, mostly used to ignore deep-throw exceptions at or near a top level (event loop).

> But, there is nothing stoping an implementation from issuing a warning for such occurrences.  It might even be a good idea. We might be able to even get agreement to include in the spec. a non-normative recommendation to that regard similarly to what ES5 has regarding function declarations within blocks.

Warnings are mostly fruitless, in my experience. Mostly meaning not that they sometimes work (they may, I just don't know), rather that sometimes they just bug the heck out of developers and cause a backlash (this happened with SpiderMonkey's strict-option warning against 'with', long before ES5 strict), or merely degrade the coin of the console.log realm.


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

More information about the es-discuss mailing list