name anonymous functions on property assignments

Allen Wirfs-Brock allen at
Sat Jan 28 15:46:54 UTC 2017

> On Jan 27, 2017, at 7:26 AM, T.J. Crowder <tj.crowder at> wrote:
> Two questions on the minor issue of the following not assigning a name
> to the function:
> ```js
> = function() { };
> ```
> 1) Am I correct that the only reason it doesn't (in spec terms) is

No, the only reason it doesn’t is: by design, as directed by a decision made within a TC39 meeting.

> that Step 1.e. of [Runtime Semantics:
> Evaluation](
> reads
>> If IsAnonymousFunctionDefinition(AssignmentExpression) and IsIdentifierRef of LeftHandSideExpression are both true, then
> and that changing that to
>> If IsAnonymousFunctionDefinition(AssignmentExpression) is true and either IsIdentifierRef of LeftHandSideExpression is true or IsPropertyReference of LeftHandSideExpression is true, then
> would mean it would assign the name `foo`?

Yes, and for 
   cache[getUserSecret(user)] = function() {};
it would leak the secret user info as the value of name

and for
   obj[someSymbol] = function() {}
it would leak the Symbol value as the value of name

and for 
   table[n]=function() {}
name would likely be a numeric string

> (The subsequent step
> getting the name to use already uses GetReferencedName, which works
> for property references as well as identifier references.)
> 2) Are there any objections to closing this gap in how function names
> are assigned?

Yes there are!

In addition to the above, note that isIdentiferRef is a static semantic operation.  That means the the determination of whether a name will be attached and the actual name can be determined statically prior to execution.   IsPropertyRef is a runtime operation and the new semantics require runtime determination of the name value.  This is all extra runtime work that may slow down the creation of function closures that appear within loops.


More information about the es-discuss mailing list