Should anonymous functions get a `name` data property?

[ajklein]

ES2015 and later give a name property to named functions (whether named via declaration, expression, or name inference). Anonymous functions aren't given one, presumably with the expectation that name lookups will read through to Function.prototype.name (which is an empty string).

Yet engines have legacy behavior here:

> eshost -e '(() => {}).hasOwnProperty("name")' // same result for function(){}
#### v8
true

#### jsc
true

#### spidermonkey
true

#### chakra
false

I'd propose that there'd be little downside to specifying this behavior.

[ljharb]

What are the same eshost results for a non-arrow function, a generator function, and an async function?

[ljharb]

What are the same eshost results for a non-arrow function, a generator function, and an async function?

[ajklein]

@ljharb all the same as the arrow function above: v8/jsc/spidermonkey all add a name property (with the value "").

[ajklein]

@ljharb all the same as the arrow function above: v8/jsc/spidermonkey all add a name property (with the value "").

[ljharb]

That strongly supports making it an own property, indeed.

[ljharb]

That strongly supports making it an own property, indeed.

[allenwb]

Is there an reason why implementations deviated from the spec? If so, what is it?

There was a reason for why it was spec'ed the way it is. If there is a strong implementation reason for the deviation then it would make sense to change the spec. But changing it just to match unjustified implementations deviations is bad precedent.

[allenwb]

Is there an reason why implementations deviated from the spec? If so, what is it?

There was a reason for why it was spec'ed the way it is. If there is a strong implementation reason for the deviation then it would make sense to change the spec. But changing it just to match unjustified implementations deviations is bad precedent.

[syg]

@ajklein What about unnamed class expressions across the engines? I see code in SM explicitly not defining .name as an own property on unnamed class exprs.

[syg]

@ajklein What about unnamed class expressions across the engines? I see code in SM explicitly not defining .name as an own property on unnamed class exprs.

[ajklein]

@allenwb I believe the engines which return true above all implemented a name property before it was added to ECMAScript in version 6. For V8, that's definitely the case; see the tracking bug for more background. From that point of view, ES2015 is the "unjustified" one in deviating from existing behavior.

@syg That's very interesting: only JSC provides a name property for an anonymous class.

[ajklein]

@allenwb I believe the engines which return true above all implemented a name property before it was added to ECMAScript in version 6. For V8, that's definitely the case; see the tracking bug for more background. From that point of view, ES2015 is the "unjustified" one in deviating from existing behavior.

@syg That's very interesting: only JSC provides a name property for an anonymous class.

[ljharb]

@allenwb could you elaborate on the reasons why this is spec'ed this way?

[ljharb]

@allenwb could you elaborate on the reasons why this is spec'ed this way?

[allenwb]

@ajklein At the time name was added to ES6 it non-standard and wasn't universally implemented by major browsers (at least IE did not implement it). I'm sure there was variation among those that did implement it, just as has been reported in this thread. Given that situations, TC39 evaluated the utility of the feature, decided it was useful, looked at specification alternatives, made some decisions, and wrote the spec. All the major implementations were represented in that process and ultimately voted to approved the final ES6 spec. If there were objections to ES6's choosen semantics, there were plenty of opportunity to raise objections. Given all that, this sounds to me like a set of implementation bugs where implementations have not been updated to match the approved standard.

Note, that the actual design point here is not a very big deal. It could have gone either way. But the whole point of having a standard is to pin down such design points so implementations don't just go off and follow their preferences.

@ljharb Why? Because an own name property whose value is "" is redundant since such a property is inherited from Function.prototype. Plus there are many anonymous function instances . All those redundant properties add up.

[allenwb]

@ajklein At the time name was added to ES6 it non-standard and wasn't universally implemented by major browsers (at least IE did not implement it). I'm sure there was variation among those that did implement it, just as has been reported in this thread. Given that situations, TC39 evaluated the utility of the feature, decided it was useful, looked at specification alternatives, made some decisions, and wrote the spec. All the major implementations were represented in that process and ultimately voted to approved the final ES6 spec. If there were objections to ES6's choosen semantics, there were plenty of opportunity to raise objections. Given all that, this sounds to me like a set of implementation bugs where implementations have not been updated to match the approved standard.

Note, that the actual design point here is not a very big deal. It could have gone either way. But the whole point of having a standard is to pin down such design points so implementations don't just go off and follow their preferences.

@ljharb Why? Because an own name property whose value is "" is redundant since such a property is inherited from Function.prototype. Plus there are many anonymous function instances . All those redundant properties add up.

[ljharb]

Thanks for clarifying, that's helpful.

[ljharb]

Thanks for clarifying, that's helpful.

[annevk]

I think unless implementations were confronted with the fact that they would have to remove functionality (and bugs were filed) it's hard to hold them accountable. It's rather easy for those kind of things to go unnoticed (as seems to have happened here). When there's existing legacy behavior you have to go the extra mile to get interoperability.

[annevk]

I think unless implementations were confronted with the fact that they would have to remove functionality (and bugs were filed) it's hard to hold them accountable. It's rather easy for those kind of things to go unnoticed (as seems to have happened here). When there's existing legacy behavior you have to go the extra mile to get interoperability.

[allenwb]

@annevk Yes, these sort of things can be missed. During the ES6 period it was really the responsibility of the TC39 representatives of various implementations to key their implementors up to date on changes and it didn't always happen.

[allenwb]

@annevk Yes, these sort of things can be missed. During the ES6 period it was really the responsibility of the TC39 representatives of various implementations to key their implementors up to date on changes and it didn't always happen.

[TimothyGu]

Marginally related: In addition to merely having a name own property, at least SpiderMonkey and V8's Proxy revocation functions have a name property that is "revoke" rather than the empty string. This seems like oversights, and thus filed at

• https://crbug.com/v8/7245
• https://bugzilla.mozilla.org/show_bug.cgi?id=1427058

[TimothyGu]

Marginally related: In addition to merely having a name own property, at least SpiderMonkey and V8's Proxy revocation functions have a name property that is "revoke" rather than the empty string. This seems like oversights, and thus filed at

• https://crbug.com/v8/7245
• https://bugzilla.mozilla.org/show_bug.cgi?id=1427058

[ajklein]

@allenwb I agree it's great to have a standard to pin down design points (and we're on the same page that this particular design choice isn't particularly important one way or the other, all things being equal). But I object to disallowing changes to those designs solely by pointing to the ratification of ES6 (especially given the size of that document and its long gestation period).

[ajklein]

@allenwb I agree it's great to have a standard to pin down design points (and we're on the same page that this particular design choice isn't particularly important one way or the other, all things being equal). But I object to disallowing changes to those designs solely by pointing to the ratification of ES6 (especially given the size of that document and its long gestation period).