rbuckton / proposal-regexp-features Goto Github PK

I have a question regarding the equivalent regex.

From what I understand, the goal of UTS#18 Line Boundaries section is to say that CRLF should be treated as if it was a single character. However, I believe that neither the current equivalent regex in this proposal ((?>\r\n?|[\x0A-\x0C\x85\u{2028}\u{2029}])) nor the one in UTF#18 ((?:\u{D A}|(?!\u{D A})[\u{A}-\u{D}\u{85}\u{2028}\u{2029}])) fulfill that goal.

The problem I see is that they still match in between CR and LF (see tc39/proposal-regexp-v-flag#42). Consider /^\r\R$/u.test("\r\n"). According to the current proposal and UTS#18, this will return true. I think this is inconsistent with the behavior of line boundary assertions (^$) in UTS#18 where the position in between CR and LF is explicitly accounted for.

Shouldn't the equivalent regexes for this proposal and UTS#18 be (?>\r\n?|(?<!\r)\n|[\x0B-\x0C\x85\u{2028}\u{2029}]) and (?:\u{D A}|(?!\u{D A})[\u{A}-\u{D}\u{85}\u{2028}\u{2029}](?<!\u{D A})) respectively?

Originally posted by @RunDevelopment in #1 (comment)

I would like to request the \G assertion. It should behave just like Java Regex's \G.

More specifically: The \G assertion consumes no characters and accepts if and only if the current cursor position is equal to the lastIndex position of the RegExp instance.

Motivation:
This is a useful feature that cannot be implemented using other regex features.

In several RegExp engines, \h works as a convenience method for specifying "horizontal whitespace". For the majority of cases you can capture these type of characters with only the space and tab characters ([\t ]) but that omits edge cases related to less commonly used, non-newline whitespace characters like en space (U+2002), em space (U+2003), and thin space (U+2009).

Essentially, \h gives you a subset of \s that omits the newline characters. Having access to this flag in ECMAScript would help me write regular expressions with greater confidence that I'll capture strings even if they contain rarely used whitespace characters:

\h Language support

Not exhaustive, but this table is based on the engines available in regex101: