github at esdiscuss.org (2013-07-12T02:25:50.906Z)
On Nov 17, 2012, at 7:25 PM, Brendan Eich wrote:
>>
>> 5. We could also allow 'let' per (4) in functions not in modules
>> that do not "use strict" but do use new ES6 syntax in their heads,
>> e.g. destructuring parameters, default parameters, rest
>> parameters. Those head features could arguably opt into 'let'
>> syntax but not strict mode.
>>
>>
>> I'd be worried that it would confusingly break refactored code:
>>
>> ```js
>> function isPermitted(user) {
>> var permissions = [].slice.call(arguments, 1),
>> let = authorize(permissions);
>>
>> if (!let) { return false; }
>> else return permissions;
>> }
>>
>> // to
>>
>> function isPermitted(user, ...permissions) {
>> var let = authorize(permissions);
>>
>> if (!let) { return false; }
>> else return permissions;
>> }
>> ```
>
> Yes, this is a downside. I don't favor (5) on this account. New syntax is its own opt-in but using a rest parameter should not opt the whole body into a different piece of new syntax.
Several times, we've discussed whether or not new function definition syntax forms (arrow functions, concise methods, the entire body of a class, generator declarations) should automatically be strict code. These are entirely new ways to write functions and to me feels like a significantly different sort of extension than the parameter variations. However, the current POR is that they are not automatically strict.
Making them always be strict would take care of many more cases where "let" is likely to be used and won't have any backwards compat. issues.
Allen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121118/c63eb4d5/attachment.html>
On Nov 17, 2012, at 7:25 PM, Brendan Eich wrote: >> >> 5. We could also allow 'let' per (4) in functions not in modules >> that do not "use strict" but do use new ES6 syntax in their heads, >> e.g. destructuring parameters, default parameters, rest >> parameters. Those head features could arguably opt into 'let' >> syntax but not strict mode. >> >> >> I'd be worried that it would confusingly break refactored code: >> >> function isPermitted(user) { >> var permissions = [].slice.call(arguments, 1), >> let = authorize(permissions); >> >> if (!let) { return false; } >> else return permissions; >> } >> >> // to >> >> function isPermitted(user, ...permissions) { >> var let = authorize(permissions); >> >> if (!let) { return false; } >> else return permissions; >> } > > Yes, this is a downside. I don't favor (5) on this account. New syntax is its own opt-in but using a rest parameter should not opt the whole body into a different piece of new syntax. Several times, we've discussed whether or not new function definition syntax forms (arrow functions, concise methods, the entire body of a class, generator declarations) should automatically be strict code. These are entirely new ways to write functions and to me feels like a significantly different sort of extension than the parameter variations. However, the current POR is that they are not automatically strict. Making them always be strict would take care of many more cases where "let" is likely to be used and won't have any backwards compat. issues. Allen -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121118/c63eb4d5/attachment.html>