January 19 meeting notes

Allen Wirfs-Brock allen at wirfs-brock.com
Fri Jan 20 10:48:35 PST 2012


On Jan 20, 2012, at 10:22 AM, Brendan Eich wrote:

>> Mark S. Miller <mailto:erights at google.com>
>> January 20, 2012 10:15 AM
>> On Fri, Jan 20, 2012 at 9:57 AM, Herby Vojčík <herby at mailbox.sk <mailto:herby at mailbox.sk>> wrote:
>> 
>> 
>>    "Single scope, args are lets" view is making sense of this. Ok,
>>    thanks.
>> 
>> 
>> Another case together with this one seems to force us into "Single scope, args are vars":
>> 
>>    function foo(e) { var e ... }
>> 
>> The "var e" is currently accepted in both strict and non-strict as a redundant declaration of the same variable, no shadowing or error. We can't break this. And we can't explain it if params are "let" bindings.
> 
> Exactly -- sorry I didn't raise this yesterday. Allen, IIRC we've discussed it. This was the reason ES4 equated let and var at top of function body or Program production (but that was in the bad old days).

I think it did come up, which is why I would actually apply the "Single scope, args are vars" (which can not be redeclared via let) rule.

In fact formals parameters are neither let or var bindings (and the specification doesn't even distinguish environment record bindings in that manner).  Classic non-strict arguments are pretty var like, but strict mode forbids multiple formals with the same name ( a let-like characteristic) and we have agreed that new syntactic forms for formal (eg destructuring) will also preclude multiple declarations of the same name even in non-strict contexts.  

>> 
>> If it turns out to be practically backwards compatible, we would like to explain "} catch (e) {" as a let binding of "e",
> 
> ES5 doesn't include "let" but essentially specifies this, and engines do it (those that support 'let' use exactly the same machinery).
> 
>> leading to a simpler explanation of its block-local scope. The hard case is
>> 
>>  } catch (e) { var e ... }
>> 
>> which would have to become an error. We don't yet know if this new breakage would create actual problems in practice.
> 
> Pretty sure we can break this. We should.

From the meeting, this was my understanding of how we will proceed.  All of the breaking changes we discussed in the context of enabling ES6 features into non-strict code are subject to reconsideration if we discover actual web breakage.

Allen


More information about the es-discuss mailing list