Should named groups really also lead to numbered captures?

[rauschma]

I don’t see an advantage in named groups creating numbered captures. And it does complicate some things. For example…

With numbered captures (line A):

const RE_DATE = /(?<year>[0-9]{4})-(?<month>[0-9]{2})-(?<day>[0-9]{2})/;
console.log('1999-12-31'.replace(RE_DATE,
    (a,y,m,d, {year, month, day}) => month+'/'+day+'/'+year)); // (A)
    // 12/31/1999

Without (line A is simpler):

const RE_DATE = /(?<year>[0-9]{4})-(?<month>[0-9]{2})-(?<day>[0-9]{2})/;
console.log('1999-12-31'.replace(RE_DATE,
    (a, {year, month, day}) => month+'/'+day+'/'+year)); // (A)
    // 12/31/1999

[littledan]

This could be fixed another way, by just passing the groups object before the numbered arguments to the replace callback.

Ultimately, this choice was done based on sort of compatibility issue. It's not really compatibility, as named groups leave the RegExp a syntax error without the feature, but if you're introducing named groups into a existing RegExp, you want to be able to continue to use surrounding code similarly. You can call this a "refactoring hazard". So, the groups argument is added towards the end.

We went back and forth on this question a bunch of times in TC39. It's still not clear to me exactly how much of a 'refactoring hazard' issue this is, but now that this proposal is at stage 3, I'd rather consider this question settled, for better or worse.

[rauschma]

Sadly, the stage 3 argument counts. I'll have to look at proposals earlier.

Still – I don’t accept the “refactoring hazard” argument:

• If you are hard-coding group numbers, you are doing something wrong.
• I would expect regular expressions to be rewritten (with names instead of numbers), not refactored. Mixing named and numbered groups seems like a bad idea.
• Not making named groups and numbered groups disjoint makes mixing them even more error-prone.

This could be fixed another way, by just passing the groups object before the numbered arguments to the replace callback.

That’s a decent work-around! I fully expect named groups to be the dominant way of writing regular expressions. And then search-and-replace shouldn’t be burdened with a complicated way of accessing the groups object.

[littledan]

Seems like the downside is from the argument ordering. We went back and forth on this. A workaround is to refer to the groups argument by the position from the end. We're at a point with two implementations, though not shipped to many users yet. If you can give feedback before stage 3, or respond to comments more quickly, it will have more possibly of being taken into account. Sorry for how this went.