Clarification on function default param values

Allen Wirfs-Brock allen at wirfs-brock.com
Tue Oct 1 11:11:48 PDT 2013


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






-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20131001/e2d2bf24/attachment.html>


More information about the es-discuss mailing list