On 29 October 2014 22:56, Allen Wirfs-Brock <[email protected]> wrote: > On Oct 29, 2014, at 4:13 PM, C. Scott Ananian <[email protected]> wrote: >> Don't forget the implications for the future. If declaring certain >> names in top level scopes is an error if they are also present in the >> global or host environment, it means that ES7+ can never define new >> names on the global (or HTML6+ can never define new names in the host >> environment) without risking hard errors in existing code. >> --scott > > A good point, even though we are only talking about let/const/class > declarations. We couldn’t want the possibility that some body has a global > let declaration for ‘Foo’ to prevent us (or a host such as the browser) from > ever defining a new built-in global named ‘Foo’. (although, I suspect there > is an argument to be made that because we now have modules that all future > global candidates should instead be exports from built-in modules). > > This brings me around to the position that let-like global instantiation > should reject let-shadowing of non-configurable property global properties > such as ‘undefined’ and ‘window’.
All good points, I agree. > The VarNames list is actually support a different case. The general case is > that we down’t allow the same name to be explicitly declared using both a > ‘var’ and a ‘let’ (etc.) declaration in any scope, including the global > scope. However, we only apply that rule to explicit global var/function > declarations. Undeclared global properties are “in the global scope” but are > not considered to be var declarations. OTOH, var declarations usually result in non-configurable properties anyway, so would already be covered by the above, once we have it. The only exception are var declarations from sloppy eval, but I suppose one could make an argument that it is fine to be able to shadow those. /Andreas _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
