What should be the function name/toString() representation of the RegExp.$&, $+, $`, $' getters

[woess]

The fact that $\&, $\+, $\`, and $\' are not valid IdentifierNames not only makes it awkward to access the property (you have to use e.g. RegExp["$&"]) but also conflicts with Function.prototype.toString()'s implied requirement that [[InitialName]] is a valid PropertyName:

2. If func is a built-in function object, return an implementation-defined String source code representation of func. The representation must have the syntax of a NativeFunction. Additionally, if func has an [[InitialName]] internal slot and func.[[InitialName]] is a String, the portion of the returned String that would be matched by NativeFunctionAccessoropt PropertyName must be the value of func.[[InitialName]].

How should this be handled?

An elegant way out would probably be to accept the suggestion in #17 and just reuse the functions named lastMatch, lastParen, leftContext, and rightContext, respectively.

[claudepache]

Another way to resolve the issue is to use the same strategy as built-in methods whose property key is a symbol, e.g.:

> String.prototype[Symbol.iterator].toString()
< "function [Symbol.iterator]() { [native code] }"

Namely, the [[InitialName]] of get RegExp.$& shall be"get ["$&"]", where ["$&"] is a valid ComputedPropertyName.

[woess]

Right. It's not pretty but this would work, albeit only with some additional spec text (in SetFunctionName presumably) that ensures [[InitialName]] is changed to ["$&"] (...) for these functions.

[bathos]

I’d think LiteralPropertyName : StringLiteral might be preferred over ComputedPropertyName for representing these names. Like for the following, just with [native code] included between the braces:

({ get "$&"() {} }).__lookupGetter__("$&").toString();
// 'get "$&"() {}'

OTOH, I’m not sure I’d be able to articulate a real rationale for this preference. It seems like using ComputedProperty is “extra complexity” — an “arbitrary” AssignmentExpression where a “static” StringLiteral could have been used instead? Given it is just a representation either way though and not code, I realize this impression of avoidable complexity is really an illusion.