Normative: allow duplicate named capture groups

[bakkot]

This allows you to have a regex like

/(?<year>[0-9]{4})-[0-9]{2}|[0-9]{2}-(?<year>[0-9]{4})/

where a capturing group name is re-used across alternatives. It continues to be illegal to re-use a name within the same alternative.

As currently specified, it also enforces that named backreferences correspond to capturing groups in the same alternative, which would make the following (currently legal) program illegal:

/(?<a>x)|\k<a>/

There is no reason to write this because the \k can never refer to anything, meaning it will always match the empty string. For this reason I think it should have been illegal in the first place. But if we want to preserve that behavior, it's easy enough to specify.

EDIT: updated so that the above remains legal, per plenary.

(I have a proposal repo for this, but figured it might as well be a PR.)

[gibson042]

The only materially necessary change I see is _j_<sup>th</sup> capture of _R_ is not *undefined* → _j_<sup>th</sup> element of _r_'s _captures_ List is not *undefined*, but I also left some suggestions that you can adopt or ignore at your discretion.

[gibson042]

Opposite polarity might lead to a more intuitive name, e.g. MutuallyExclusive.

[msaboff]

I agree with @gibson042, the sense of the CanBothParticipate AO is confusing. It returns true when x and y are in the same Alternative and therefore we should throw a Syntax Error. Can we rename CanBothParticipate to CannotBothParticipate?

[michaelficarra]

It's more like MightBothParticipate. As in, both could be components of a single match.

[gibson042]

Would this be better expressed more procedurally?

Suggested change

	1. For each integer _j_ such that _j_ ≠ _i_, _j_ ≥ 1, and _j_ ≤ _n_, do
	1. If the _j_<sup>th</sup> capture of _R_ was defined with a |GroupName|, then
	1. For each integer _j_ such that _j_ &ge; 1 and _j_ &le; _n_, in ascending order, do
	1. If _j_ &ne; _i_ and the _j_<sup>th</sup> capture of _R_ was defined with a |GroupName|, then

[gibson042]

I would not object to refactoring these aliases, e.g. s → groupName and sj → otherName.

[syg]

Happy do defer the editorial review, I'm told there've been enough eyes on this.

[jmdyck]

1. PR various editorial changes for comparisons #2877 says to avoid "is the same as", use "is" for comparing Strings.

2. It's rare (though not unheard of) to invoke an SDO with parenthesis notation. On the other hand, using the normal notation would put CapturingGroupName of _y_ on the RHS of is, which I don't think we ever do.

3. ... for which A and such that B is odd. Seems like either the two arms should agree re "for which" vs "such that", or else just use one that covers both arms: ... such that A and B

Suggested change

	It is a Syntax Error if |Pattern| contains two distinct |GroupSpecifier|s _x_ and _y_ for which CapturingGroupName(_x_) is the same as CapturingGroupName(_y_) and such that CanBothParticipate(_x_, _y_) is *true*.
	It is a Syntax Error if |Pattern| contains two distinct |GroupSpecifier|s _x_ and _y_ such that CapturingGroupName(_x_) is CapturingGroupName(_y_) and CanBothParticipate(_x_, _y_) is *true*.

[bakkot]

Changed to

It is a Syntax Error if |Pattern| contains two distinct |GroupSpecifier|s _x_ and _y_ such that the CapturingGroupName of _x_ is the CapturingGroupName of _y_ and such that CanBothParticipate(_x_, _y_) is *true*.

[michaelficarra]

LGTM other than @jmdyck's nits.

[bakkot]

Comments addressed.