3 and 7 both seems good. Personally I prefer #7 but I'm worried that it might be too surprising that arguments refers to the outer function.
On Tue, Oct 1, 2013 at 11:11 AM, Allen Wirfs-Brock <[email protected]> wrote: > > On Oct 1, 2013, at 12:03 AM, André Bargull wrote: > >> Brandon Benvie <mailto:bbenvie at mozilla.com> >> September 30, 2013 8:48 PM >> I'm actually now really curious what the following does: >> >> ``` >> function foo(x, y = (() => { arguments[0] = "foo"; return "bar" })()) { >> return [x, y]; >> } > > Easy: arguments is an early error in the body of an arrow. > > http://wiki.ecmascript.org/doku.php?id=harmony:arrow_function_syntax > > /be > > > This restriction is not specified in the rev19 draft. Currently arrow > functions don't have an own `arguments` binding, but instead access the > outer functions `arguments` object, similar to `this`. Disallowing the > identifier "arguments" in PrimaryExpressions also should imply disallowing > "arguments" as a BindingIdentifier, which shifts arrow functions again into > "almost strict-mode". > > - André > > > The restriction we want and how to enforce it is not all that clear. > > We don't really want to have an "almost strict" mode for the body of arrow > functions, if that was going to be the case I think it would be much better > to simply say that arrow functions are always strict. > > The spec. currently applies the static semantics of strict mode formal > parameters (no duplicate names, can't name a parameter 'eval' or > 'arguments') to arrow function formal parameters, but in all other ways both > the formal parameter list (think default value expressions) and the arrow > function body follow the strictness of the surrounding code. > > that means things like the following are valid in non-strict arrow > functions: > > () => {function arguments() {}; return arguments} > () => {let arguments =5; ...} > > So we can't just statically disallow 'arguments' references in a ConciseBodu > > Also, we have to have consistent behavior for an > eval('arguments') > that appears in a ConciseBody. > > Here are possible reasonable alternatives for handling arguments in arrow > functions: > > 1) nothing special, same rules as a FunctionExpression. An arguments object > is available and strict/non-strict distinctions apply both statically and > dynamically. > > 2) nothing special, but strict arguments object. Just like #1 except it > always has a strict mode arguments object (no joining of augments elements > and formal parameters > > 3) #2, plus strict mode parameter naming restrictions are also applied (no > duplicates, can't use 'eval' or 'arguments' as parameter names) > > 4) no-arguments objects with shadowing, 'arguments' binds to undefined. > Arrow functions do not have an arguments objects but they have an implicit > constant binding of 'arguments' in their parameter scope whose value is > undefined. References to 'arguments' in the body evaluate to undefined. > (unless, non-strict and there are explicit declarations of the name > 'arguments'); > > 5) no-arguments objects with shadowing, 'arguments' is in temporal dead > zone. Arrow functions do not have an arguments objects but they have an > implicit binding of 'arguments' in their parameter scope that is never > marked as initialized. References to 'arguments' in the body throw because > they are temporal dead zone references. (unless, non-strict and there are > explicit declarations of the name 'arguments' that shadow the parameter > level binding); > > 6) nothing special, but no arguments object, normal lexical scoping. Like #1 > except that there is no arguments object or local binding of 'arguments'. > References to arguments resolve via the enclosing scope. > > 7) strict mode name restrictions, but no arguments object, normal lexical > scoping. Like #3 except that there is no arguments object or local binding > of 'arguments'. References to arguments resolve via the enclosing scope. > > The rev19 spec. current has approximately #7 but there isn't anything final > about that. It sounds to me like some think either #3 or #4 is the plan of > record although I don't think we've talked about it at a TC39 meeting that > this level of detail. > > I think #3 would be a good solution. So is #7. > > #3 probably would seem reasonable to JS programmers. #7 probably is what > lexical scoping heads would expect. #4 or #5 is a completely new semantics > that I don't think anyone expects. > > Allen > > > > > > > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > -- erik _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
