[SEARCHING] Difference between `\g` and `\k` is not addressed.

[pbarney]

I just spent an hour delving into the possible differences between \g and \k, of which there are no satisfactory answers, and a few wrong answers. This eventually led me to digging into Boost's source code.

The short explanation is that there is no difference between \g and \k other than the history behind each.

Boost's source code treats them identically: regex_traits_defaults.hpp maps both characters to the exact same internal token:

escape_type_extended_backref, /*g*/
...
escape_type_extended_backref, /*k*/

...and basic_regex_parser.hpp has one single case for escape_type_extended_backref. It never checks if the original character was g or k.

After digging a little more, it turns out it's just a historical choice based on Perl's implementation that Boost chose to extend.

For this reason, I think it would be worthwhile mentioning this in the documentation.

My proposed change would be to add the following under the Capture Groups and Backreferences section of the Searching page:

• \g and \k are functionally synonymous prefixes for extended backreferences. There is no semantic difference in Boost's implementation. They coexist for syntax-compatibility/historical reasons.

I'm about to make a PR for this change.

[pryrt]

I just spent an hour delving into the possible differences between \g and \k

I am not sure why. The \gℕ, \g{ℕ}, \g<ℕ>, \g'ℕ', \kℕ, \k{ℕ}, \k<ℕ> or \k'ℕ' are all defined with the same definition, and no notes indicating there is any difference, other than on the sign of the ℕ, so I don't see why there would be ambiguity.

But since at least one person thinks there's ambiguity, I will approve it, once the edit is in a logically-appropriate location.

[pbarney]

I don't see why there would be ambiguity.

It's the implication that comes out of the existence of two identical tokens. It begs the question, "why?"

If there's no answer to that question provided, then the implication is that there is probably a difference, but it wasn't addressed in the documentation.

I suppose someone might also land on, "there's no difference, they just wanted two identical tokens," but that's not something a well-written regex parser is likely to do for no reason.

That's why I felt an explanation was a good idea, at least for those of us who like to understand the tools we use.