Argument order for callable replaceValue

[schuay]

As a suggestion to improve ergonomics of @@replace calls with a callable replaceValue: passing namedCaptures to replaceValue as the second argument would allow a generic

function replacer(match, groups) {
  // Use captures from the groups object.
}

to handle RegExp's with varying capture counts.

This would be an improvement over the current state where one needs to either adapt the replacer signature for different capture counts, or use the arguments object.

[hashseed]

Rest parameters would be an alternative with the current proposal, but it doesn't seem concise nor ergonomic.

In hindsight, having variable length arguments in the middle of the arguments list was a bad idea in the first place.

[littledan]

@schuay Slight tweak: Do you still want the position and entire string as arguments? They could go after the groups object, maybe.

We'd previously considered various other argument positions. This proposal is based on the idea that compatibility isn't important since we're only changing the argument order of RegExps with groups in them. We got to Stage 3 on the conservative argument ordering, but I'm wondering if people might still consider this one. cc people active in past conversation about this: @ljharb @bterlson @allenwb @michaelficarra @BrendanEich

[schuay]

@littledan I wasn't suggesting changing other replaceValue arguments. I guess it may be valid to do so, but I'm not aware of the history on this; and it doesn't sound right to me to completely change the replacer signature depending on whether named captures exist or not.

[ljharb]

I think compatibility is very important, if possible to obtain, because old replacers will start getting called with new regexes.

[littledan]

@ljharb Do you have an example of this? It's hard to imagine how they will be used, as different RegExps have different numbers of numbered groups.

[ljharb]

@littledan (sorry for the delayed response) a replacer that reflected on the arguments object: Array.prototype.slice.call(arguments, -2) would always return [position, string], and Array.prototype.slice.call(arguments, 0, 1) always the matched item, and Array.prototype.slice.call(arguments, 1, -2) always the list of captures.

[hax]

@littledan There will always be edge cases break compatibility whichever position we choose.

If JS support (...args, last) like Python, there will be no ergonomics problem. Is that path possible?

[littledan]

@hax As far as ergonomics goes, arguably it's prettier to not have the ...args first, isn't it?

[hax]

@littledan Sorry, I should @ljharb in last comment.

About ergonomics, I'm just curious why JS does not support (...args, x, y), I have several times see some programmers write similar code and they were surprised to got syntax errors.

[littledan]

@hax Yeah, that seems like a good idea, and I don't see why we couldn't do it. Maybe we could get into details on another thread though.