In Go's regexp package, how do you read a named capture group out of a match?

## Naming a group A capture group is named in the pattern itself with the syntax `(?P<name>re)` — for example `(?P<key>\w+)=(?P<val>\d+)`. Recent Go also accepts the shorter `(?<name>re)` spelling for the same thing. Naming changes nothing about matching: the group still captures, still occupies a numbered slot, and still counts toward `NumSubexp()`. What the name buys you is a stable way to find that slot without hard-coding a number that shifts the moment somebody adds a group earlier in the pattern. ## The match slice is still numbered This is the point people miss. `FindStringSubmatch` returns a plain `[]string` indexed by number, exactly as it does for an unnamed pattern. There is no `m["key"]`. The names are metadata on the *compiled pattern*, so you ask the pattern for the number and then index the match: ```go re := regexp.MustCompile(`(?P<key>\w+)=(?P<val>\d+)`) m := re.FindStringSubmatch("retries=5") if m != nil { fmt.Println(m[re.SubexpIndex("val")]) // 5 } ``` ## SubexpIndex `func (re *Regexp) SubexpIndex(name string) int` returns the index of the first subexpression with that name, or **`-1`** if the pattern has no group by that name. `-1` is a perfectly ordinary `int`, so `m[re.SubexpIndex("typo")]` panics with an out-of-range index rather than failing politely. Because the pattern is a constant of the program, the honest place to catch a typo is once at startup: ```go keyIdx := re.SubexpIndex("key") if keyIdx < 0 { panic("pattern lost its key group") } ``` That converts a mid-run panic on some unlucky input line into a failure the first test run catches. ## SubexpNames `func (re *Regexp) SubexpNames() []string` returns the names of all the parenthesized subexpressions, and its layout is deliberately parallel to a match slice: - its length is `NumSubexp() + 1`, the same as any slice `FindStringSubmatch` returns; - **slot 0 is always the empty string**, because slot 0 of a match is the whole matched text, which is not a group and cannot be named; - an unnamed group carries `""` at its index; - a named group carries its name at its index. For `(?P<key>\w+)=(?P<val>\d+)` the result is `[]string{"", "key", "val"}`. The returned slice must not be modified — it belongs to the compiled pattern, which may be shared. That parallel layout makes one loop the canonical way to turn a match into a map: ```go fields := map[string]string{} for i, name := range re.SubexpNames() { if i > 0 && name != "" { fields[name] = m[i] } } ``` The `i > 0` test skips the whole-match slot and the `name != ""` test skips unnamed groups, so the map holds exactly the named captures. Note that a named group which took part in no match contributes an empty string here, indistinguishable from one that matched empty text — the same limitation the numbered API has. ## Why names are worth the noise A pattern like `^(\S+)\s+(\S+)\s+(\S+)$` is read by counting parentheses, and every reader counts again. Worse, wrapping an existing group or inserting an alternative renumbers everything after it, and the code that indexes `m[2]` keeps compiling while silently reading the wrong field. Naming both documents the pattern inline and makes the extraction survive edits, at the cost of a slightly denser expression. Names also carry over to replacement templates: `ReplaceAllString` expands `${key}` using exactly the names `SubexpNames` reports, so one naming decision serves both reading and rewriting. ## Debugging alignment When a match does not contain what you expected, the fastest diagnostic is to print `SubexpNames()` and the match slice together — two slices of the same length, side by side — for one line that matches and one that does not. Misalignment, an unnamed group you forgot about, or a `-1` from `SubexpIndex` becomes obvious in one glance, and it takes far less time than re-reading the regular expression.