Path to Stage 4!

[ljharb]

Stage 4

• committee approval
• two implementations
  • chrome / node (bug)
  • firefox (in nightly) (intent to ship in v134) shipped in v134
  • safari (PR 1, PR 2)
    • STP
    • 18.2
  • es-shims polyfill
  • core-js polyfill
• significant in-the-field experience
• ecma262 PR approved
• prepare ecma262 PR

Stage 3

• committee approval
• merge test262 tests
• write test262 tests (issue, PR)

Stage 2.7

• committee approval
• spec editor signoff
  • @syg
  • @bakkot
• spec reviewer signoff
  • @jridgewell (Spec Review #60)
  • @michaelficarra
  • @gibson042
• resolve [spec] handle surrogate pairs #71
• resolve EncodeForRegExpEscape should not return results that require particular flags #69
• resolve change escaping to hex escape sequences #65
• resolve Which leading characters should be escaped? #66
• resolve hex escapes vs character escapes
• update spec to make escapes legal noops in u/v mode
  • /u flag vs. /v flag #55
  • Ensure the result works with the u flag #52

Stage 2

• committee approval
• spec reviewers selected
• spec text written

Stage 1

• committee approval

[oliverfoster]

Congratulations on getting to Stage 2. 👍

[benjamingr]

Hey, need help on any of these? (I'm happy to try and contribute the test262 tests or amend the spec according to the consensus)

[ljharb]

I'm comfortable handling the spec, but the test262 tests would be most helpful. Be warned, though, they'll need to be extremely rigorous.

[jridgewell]

My review is at #60

[michaelficarra]

My feedback:

1. I don't like how this is introducing identity escapes in Unicode mode for these new punctuators. This wasn't a goal of the RegExp escaping proposal. You can accomplish RegExp escaping with hex escapes and without introducing new features to the RegExp grammar.
2. There's no reason to define the phrase "the ASCII punctuators that need escaping" if it's just used once, in the algorithm that follows. Just inline the string. Also I don't like how the string is denoted since it contains a ". Can you figure out some other way to denote it?

Maybe a table (code point, hex escape string) would solve both of my issues.

[ljharb]

For the second, I have no strong opinions about how to denote the characters; I can certainly inline the string.

For the first, isn't that required, otherwise this proposal won't be able to produce output that works in both u and v mode?

[michaelficarra]

No, I believe hex escapes are sufficient for this purpose. Do you have a specific counterexample?

[ljharb]

cc @bakkot since this was a result of their research

[bakkot]

Hex encoding works, it just makes the output completely unreadable. I can't imagine we're going to make \& mean anything other than & in u-mode regexps, so I don't think there's much cost in making those legal, and I think we ought to pay that cost for the benefit of more readable output.

[michaelficarra]

I do not value the readability of the output. This function is meant only for composing and then compiling RegExps.

[bakkot]

Sometimes you have to debug compiled regexps.

[michaelficarra]

You can decompile them and represent them however you like. Paste them into a visualiser.

[bakkot]

That's a bunch more work than doing console.log(regex). Why should anyone have to do that work? That's a very concrete cost to your suggestion and I see approximately no offsetting benefit. What benefit do you see to your suggestion?

[ljharb]

@michaelficarra as far as the spec review goes, I've addressed your editorial comment; can I check you off?

The normative one we can certainly discuss further if needed.

[michaelficarra]

The spec text is fine for what you intended. I still have issue with the escaping design though.