Clarification on function default param values

Erik Arvidsson erik.arvidsson at gmail.com
Tue Oct 1 11:19:45 PDT 2013


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
<allen at wirfs-brock.com> 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
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>



-- 
erik


More information about the es-discuss mailing list