Clarification on function default param values

Mark S. Miller erights at google.com
Tue Oct 1 11:59:50 PDT 2013


I agree that the discussions as I remember them do not go into this level
of detail. Thanks for being so explicit about precise choices.

However, I do recall that the consensus we had was enough to rule out #3,
or indeed any solution where arrow functions have their own arguments
object. And even if I recall wrongly, I do think arrow functions should not
get their own arguments object -- that's too surprising from an
arrow-function-as-smalltalk-block-like perspective.

#7 can be explained in a memorable way:

Generally variables are brought into scope by an explicitly appearing
defining occurrence. Two exceptions are the "function" brings into scope
both "this" and "arguments". These remain in scope until shadowed by a
nested "function" or by an explicit definition. Note that "this" can never
be explicitly defined, and "arguments" can only be explicitly defined in
non-strict code.

As of ES6, a variety of other function-defining constructs, like
"function", implicitly bring into scope a new "this" and "argument".
Arrow-functions are not one of these. Within an arrow function, both "this"
and "arguments" are lexically captured from the enclosing context.




On Tue, Oct 1, 2013 at 11:19 AM, Erik Arvidsson <erik.arvidsson at gmail.com>wrote:

> 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
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>



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


More information about the es-discuss mailing list