Regular Expression Pattern Modifiers for ECMAScript

Status

Stage: 4
Champion: Ron Buckton (@rbuckton)

For detailed status of this proposal see TODO, below.

Authors

• Ron Buckton (@rbuckton)

Motivations

One common capability amongst the majority of regular expression engines that is commonly used by parsers, syntax highlighters, and other tools is the capability to control a subset of regular expression flags such as:

• i — Ignore Case
• m — Multiline
• s — Single-line (a.k.a. "dot all")
• x — Extended mode (see https://github.com/rbuckton/proposal-regexp-x-mode)

Modifiers are especially helpful when regular expressions are defined in a context where executable code cannot be evaluated, such as a JSON configuration file or TextMate tmLanguage grammar file.

As part of this proposal, we will investigate each existing (and future-proposed) RegExp flag to determine whether they are feasible to used as modifiers.

Prior Art

• Perl
• PCRE
• Boost.Regex
• .NET
• Oniguruma
• Hyperscan
• ICU
• Glib/GRegex

See https://rbuckton.github.io/regexp-features/features/modifiers.html for additional information.

Syntax

Modifiers allow you to change the currently active RegExp flags within a subexpression.

• (?imsx-imsx:subexpression) — Sets or unsets (using -) the specified RegExp flags for the subexpression.
• (?imsx-imsx) — Sets or unsets (using -) the specified RegExp flags starting at the current position until the next closing ) or the end of the pattern.

NOTE: Certain flags cannot be modified mid-expression. These currently include g (global), y (sticky), u (unicode), and d (hasIndices).

NOTE: The actual supported flags will be determined on a case-by-case basis. See #1.

NOTE: This has no conflicts with existing syntax, as ECMAScript currently produces an error for this syntax in both u and non-u modes.

NOTE: The "self-bounded" form ((?imsx-imsx:subexpression)) advanced to Stage 2 on December 15th, 2021.

NOTE: The "unbounded" form ((?imsx-imsx)) is no longer being considered as part of this proposal as of December 15th, 2021.

Examples

const re1 = /^[a-z](?-i:[a-z])$/i;
re1.test("ab"); // true
re1.test("Ab"); // true
re1.test("aB"); // false

const re2 = /^(?i:[a-z])[a-z]$/;
re2.test("ab"); // true
re2.test("Ab"); // true
re2.test("aB"); // false

History

• October 27th, 2021 — Proposed for Stage 1 (slides)
  • Outcome: Advanced to Stage 1
• December 15th, 2021 — Proposed for Stage 2 (slides)
  • Outcome: Advanced to Stage 2 with "self-bounded" form only ("unbounded" form did not advance).
  • Stage 2 Reviewers: Richard Gibson, Waldemar Horwat
• June 7th, 2022 — Proposed for Stage 3 (slides)
  • Outcome: Advanced to Stage 3

TODO

The following is a high-level list of tasks to progress through each stage of the TC39 proposal process:

Stage 1 Entrance Criteria

• Identified a "champion" who will advance the addition.
• Prose outlining the problem or need and the general shape of a solution.
• Illustrative examples of usage.
• High-level API.

Stage 2 Entrance Criteria

• Initial specification text.
• Transpiler support (Optional).

Stage 2.7 Entrance Criteria

• Complete specification text.
• Designated reviewers have signed off on the current spec text (1 of 2).
• The ECMAScript editor has signed off on the current spec text.

Stage 3 Entrance Criteria

• Test262 acceptance tests have been written for mainline usage scenarios and merged.

Stage 4 Entrance Criteria

• Two compatible implementations which pass the acceptance tests:
  • V8 - Shipping in Chrome 125/Edge 125
  • SpiderMonkey - Shipping in FireFox 130 behind a flag, Shipping in FireFox 132b (Nightly) unflagged
  • JSC
  • Engine262
• A pull request has been sent to tc39/ecma262 with the integrated spec text.
• The ECMAScript editor has signed off on the pull request.
  • Kevin Gibbons
  • Michael Ficarra