In a regular expression with nested capture groups, how are the group numbers assigned?

## Numbering follows the opening parenthesis The rule is short and entirely syntactic: **scan the pattern left to right and number each capturing `(` as you meet it**. The number is fixed by the text of the pattern, before any input is seen, and it does not depend on which alternatives end up participating. The consequence people trip over is nesting. Because the *opening* parenthesis decides, an outer group is always numbered before the groups it contains — numbering runs outside in, not inside out. ## A worked example Pattern `((\w+)=(\w+))` against the field `user=alice`: | group | how it is reached | text after the match | |---|---|---| | 0 | the whole match, by convention | `user=alice` | | 1 | first `(` — the outer group | `user=alice` | | 2 | second `(` — nested, before `=` | `user` | | 3 | third `(` — nested, after `=` | `alice` | Read it by counting parentheses in the pattern, never by counting the interesting pieces in the output. A weak answer reports `user` as group 1 because it is the first *interesting* value; the outer group came first in the text and took the number. ## Groups that take no number - `(?:...)` — a **non-capturing group**. It exists for precedence and for applying a quantifier to a sequence. It stores nothing and takes no number, so adding or removing one never renumbers the groups after it. - Lookahead and lookbehind constructs likewise group without capturing, though any capturing group written *inside* them does take a number. - A **named group** normally has both a name and a number; the name is an alias, not a replacement, so mixing named and unnamed groups still shifts the positional numbers. This is why patterns that are edited often are better written with non-capturing groups everywhere except the pieces you actually read: every stray pair of parentheses added for precedence otherwise renumbers everything downstream, and the code that reads group 3 silently starts reading something else. ## A capturing group inside a repeat What happens when a capturing group is itself repeated? Each iteration overwrites the group's contents, so once the match finishes the group holds the text of its **last successful iteration** — that is the usual convention, and the alternative of accumulating every iteration is rare enough that you should not assume it. For `(?:(\d+),)+` against `1,2,3,`: 1. The repeat runs three times. 2. Group 1 captures `1`, then `2`, then `3`, each overwriting the previous value. 3. After the match, group 1 holds `3` — the other two are gone. So a pattern shaped like this can tell you *that* a comma-separated list matched and give you the whole span, but it cannot hand back the items. To get every element you match the list once as a whole and split it, or you iterate matches of the element pattern across the span. This is one of the most common surprises in real extraction code. ## Participated, unset, and empty A group in a branch that was never taken — `(a)|(b)` where the second alternative won — did not participate. Conventions differ on how that is reported: some distinguish an unset group from one that matched empty text, others surface both as an empty value. Since a group *can* legitimately match the empty string (`(x*)` against `y`), "empty" and "absent" are genuinely different facts, and code that treats them as the same silently turns a missing optional field into a present blank one. Where the distinction matters, check participation explicitly rather than inferring it from the text. ## Practical habits - Count parentheses, not values, when you are working out a number. - Use non-capturing groups for everything you do not read, so numbering is stable under edits. - Prefer names over numbers in any pattern long enough to need a comment. - Never expect a repeated group to hand back its history; restructure the extraction instead. - Treat an optional group's absence as a distinct case from an empty capture.