`Function.prototype.toString` for a built-in function with a name that is invalid as an identifier about test262 HOT 4 OPEN

I would assume that it indeed outputs with the square brackets and quotes.

In my Safari, it outputs function $+() { as the first line; in Chrome, it outputs function get $+() {; in FF, it matches Safari.

The spec allows a lot of things that are unwise; I would hope that since the browsers don't agree, that it would be feasible (altho surely low priority) for them all to change to the reasonable thing?

from test262.

FWIW: This issue is also filed at https://bugzilla.mozilla.org/show_bug.cgi?id=1658492.

from test262.

However, how should we handle the result of Function.prototype.toString for built-in functions with invalid names as identifiers (e.g., RegExp["$+"] that is not standardized yet)?

It is not standardized yet, but it is part of https://github.com/tc39/proposal-regexp-legacy-features which is a stage 3 proposal. Therefore it's fair game to have tests in test262 for it.

By my reading, the unambiguously correct output according to the spec is function get $+() { [native code] } so I'd say that's what we should test for, but...

I'd suggest opening an issue in that proposal. In ECMA-262 as far as I know, there are no builtin functions that have a name that is a String but isn't a LiteralPropertyName, so step 4 of SetFunctionName has no need to emit a ComputedPropertyName when name is a String. With the introduction of Legacy RegExp Features, that assumption becomes incorrect (note that it might not be an intended assumption, though.) This seems like it's worth bringing a normative change to committee.

from test262.

Actually, I see there already is such an issue: tc39/proposal-regexp-legacy-features#19

from test262.