necessity of k in backreference over \<name>

[jnvm]

Numbered backreferences, the only current backreference, have no prefix character associated with them:

/f(o)\1/.test('foo')

This proposal gives named group backreferences a \k prefix before the <name>.

/f(?<x>o)(\k<x>)/.test('foo')

My suggestion is: why not just \<name>, without the k?

/f(?<x>o)(\<x>)/.test('foo')

As I see it:

• \<name> more closely resembles the concept's current syntax, which requires no prefix character
• \<name> is shorter, which may be more valuable given regex are usually terse
• \<name> has only essential parts, which seems desirable in a pattern matching language: if the k will always be there, and the < name > will too, <> are delimiters, \< can trigger the logical fork; k seems like noise
• \<name> is as backwards compatible as the current suggestion for regular & /u cases
• \<name> does not muddy the meaning of the current "backslash-letter" syntax for character classes (\d|\D means [0-9]|[^0-9], etc) with the wholly different concept of backreferences.
• \k can be something else later

The only arguments I can see against this are:

• \k already means something in Perl, Java, .Net, and Ruby which do use \k<name>
  • (but Python doesn't, and surely other languages don't either--and loads of other discrepancies between them all & js already)
• I guess \<.*> can't mean something else later?
• This introduces some ambiguity either now or likely in the future that I do not see.

Is there a syntactic / functional reason the k needs to be there?

[littledan]

A couple reasons why I think \k< makes more sense than \<:

• \k seems to be the consensus choice from other RegExp languages (Python and PHP are one-off outliners here).
• \< often means opening word break in other RegExp languages, so this differing use could be confusing

This proposal is at Stage 3, so I'd prefer to not make changes like this anymore unless the reason is very strong and clear-cut, leaving most changes to be based on implementation feedback.