<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Aug 24, 2011, at 2:01 AM, Andreas Rossberg wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>On 23 August 2011 19:14, Allen Wirfs-Brock <<a href="mailto:allen@wirfs-brock.com">allen@wirfs-brock.com</a>> wrote:<br><blockquote type="cite"><br></blockquote><font class="Apple-style-span" color="#006312"><br></font>Oh, but that description does not cover Dave's exact example, which actually was<br><br>{ { let x; { var x } } }<br><br>Here, the var is hoisted across the let's scope, but doesn't end up in<br>the same scope. And we clearly want to rule that out, too. But then,<br>you also want to properly distinguish this case from, say<br></div></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div><br></div><div>Allen</div></div></body></html>