At what point is it safe to say "The committee is not interested in .escape"?

[benjamingr]

Hey,

In the past, WHATWG has expressed interest in standardizing RegExp.escape as a utility as part of the web platform. We (Node) want this and I'm happy to push this through WHATWG and other standards bodies I'm involved with (like WinterCG) to other server platforms.

As it was suggested to me by committee members and as a show of good faith - I pushed back on this idea to standardize through TC39 as that was the nice thing to do to the disappointment of users.

That was over 2 years ago.

When would be a good time to say "OK, it looks like the committee is blocked on the solution the community is asking for" and pursue it in another way the platform I help maintain and other platforms can use it?

[ljharb]

When the committee indicates that - the last time it was brought up in committee, they were interested. It’s just that i haven’t had time to make another presentation to TC39.

[ljharb]

RegExp.escape advanced to stage 2 today.

[bakkot]

With the Extended "Safe" Proposal semantics [except for A-F at the start of strings, which is less necessary], but also escaping all the other ascii punctuators, in case they need to be used for some later feature.

So it's pretty aggressive with the escaping, but it'll work.

[coolaj86]

I think that's a bit too aggressive. It should be understood that mixing escaped and unescaped strings leads to undefined behavior (it seems the sort of thing that someone learning about string security learns by very virtue of learning about escaping strings at all).

Perhaps instead there should be a companion proposal for a RegExp builder: RegExp.concat(a, RegExp.escape(b), c) or RegExp.tmpl`${a} ${RegExp.escape(b)} ${c}`. (similar to SQL builders)

And, ideally, new RegExp and RegExp.escape would always be updated simultaneously, so it wouldn't be necessary to over-escape things. (though I can also envision a scenario where someone isn't using it directly, but shoves the result in a database or some such... which seems a bit weird but... 🤷‍♂️)

That said, I'll certainly be happier to have it in than not. It does seem to be a unfortunate dependency via npm.

[bakkot]

@coolaj86 The conflict between a desire for the simple API and a desire for a builder API is what has prevented any progress on this proposal for the last eight years.

And we've found that changing the output of functions like this in the future is often not web-compatible (for example, someone might be using the output in their own custom RegExp implementation), so we are unlikely to be able to update in the future.