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
