Ecma262: Is /[\k](?<a>)/ legal?

[bakkot]

In JSC, V8, and XS, /[\k](?<a>)/ is a legal regular expression. (Chakra and Spidermonkey do not implement named capturing groups and therefore reject it for that reason.)

However, my reading of the spec says it should not be legal: ParsePattern says that the presence of a group name after the initial parse should cause a reparse with +N, which means that Annex B's SourceCharacterIdentityEscape should not allow \k. (Assuming the obvious fix to https://github.com/tc39/ecma262/issues/1081, which would thread the +N through ClassAtomNoDash -> ClassEscape -> CharacterEscape -> IdentityEscape -> SourceCharacterIdentityEscape.)

[shvaikalesh]

However, my reading of the spec says it should not be legal: ParsePattern says that the presence of a group name after the initial parse should cause a reparse with +N, which means that Annex B's SourceCharacterIdentityEscape should not allow \k.

This matches my reading of the spec; r259026 made /[\k](?<a>)/ an early SyntaxError in JSC (available in Safari TP).

@mathiasbynens would you consider aligning with JSC (and the current spec) if I add a test262 coverage?

[mathiasbynens]

would you consider aligning with JSC (and the current spec) if I add a test262 coverage?

@schuay what do you think?

[schuay]

would you consider aligning with JSC (and the current spec) if I add a test262 coverage?

@schuay what do you think?

For throwing the SyntaxError, sure, thanks for the heads up. Opened https://crbug.com/v8/10602. (Early errors are another topic https://crbug.com/v8/896.)

[michaelficarra]

I think \k in a character class should just be a k. Like how [\z] is the same as [z] (or z).

[waldemarhorwat]

\k in a character class should do the same thing as \k not in a character class. This is what the spec currently states and we shouldn't change that.

[michaelficarra]

@waldemarhorwat Why? A lot of things are different in character classes.

[shvaikalesh]

@michaelficarra [\z] is the same as [z] due to IdentityEscape of Annex B. In Unicode patterns, it is an early SyntaxError.

If a pattern contains named capture group, we can apply stricter parsing rules (and make [\k] illegal) without backwards-compatibility risk, bringing a slightly better DX.

Implementation-wise (YARR), it is a tiny bit easier to throw than to allow it.

[jmdyck]

If a pattern contains named capture group, we can apply stricter parsing rules (and make [\k] illegal)

We already do:
SourceCharacterIdentityEscape[N] :: [+N] SourceCharacter but not one of c or k