How is escaping of plain text affected by this proposal?

[rauschma]

• I take it, it’s best to now escape all punctuation characters listed in this section? https://github.com/tc39/proposal-regexp-v-flag#how-is-the-v-flag-different-from-the-u-flag
• Does this affect the escaping proposal – specifically, this list? https://github.com/tc39/proposal-regex-escaping/blob/main/EscapedChars.md

I’m currently using this function to escape plain text – which will have to change(?)

export function escapeForRegExp(str: string) {
  return str.replace(/[\\^$.*+?()\[\]{}|=!<>:\-]/g, '\\$&');
}

It may make sense to show an implementation of such a function in this proposal or to link to one elsewhere.

[mathiasbynens]

The list of characters in the second bullet point of https://github.com/tc39/proposal-regexp-v-flag#how-is-the-v-flag-different-from-the-u-flag that are not in https://github.com/tc39/proposal-regex-escaping/blob/d2ff7fe02009f728eb3c2e749e354c72427abd08/EscapedChars.md#syntaxcharacter-proposal is:

/
-
&
!
#
%
,
:
;
<
=
>
@
`
~

If the RegExp escaping proposal wants to support using its output within a character class in v mode, these would need to be added. However, u mode currently disallows unnecessary escapes, e.g. /</u is fine but /\</u is an early syntax error — so the escaping proposal cannot satisfy both u and v at the same time. This is something for the escaping proposal champions to look into.

[rauschma]

Hmm. Seems problematic. Is changing /u to allow unnecessary escapes an option?

Edit – yes that is an option: #27

[ljharb]

That sounds to me like a cross-cutting concern that this proposal needs to account for before advancing.