Regular Expression Pattern Modifiers for ECMAScript
Status
Stage: 1
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 Casem
— Multilines
— 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
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)
— Sets or unsets (using-
) the specified RegExp flags starting at the current position until the next closing)
or the end of the pattern.(?imsx-imsx:subexpression)
— Sets or unsets (using-
) the specified RegExp flags for the subexpression.
NOTE: Certain flags cannot be modified mid-expression. These currently include
g
(global),y
(sticky), andd
(hasIndices).
NOTE: The actual supported flags will be determined on a case-by-case basis.
NOTE: This has no conflicts with existing syntax, as ECMAScript currently produces an error for this syntax in both
u
and non-u
modes.
Examples
const re1 = /^(?i)[a-z](?-i)[a-z]$/;
re1.test("ab"); // true
re1.test("Ab"); // true
re1.test("aB"); // false
const re2 = /^(?i:[a-z](?-i:[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
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 3 Entrance Criteria
- Complete specification text.
- Designated reviewers have signed off on the current spec text.
- The ECMAScript editor has signed off on the current spec text.
Stage 4 Entrance Criteria
- Test262 acceptance tests have been written for mainline usage scenarios and merged.
- Two compatible implementations which pass the acceptance tests: [1], [2].
- A pull request has been sent to tc39/ecma262 with the integrated spec text.
- The ECMAScript editor has signed off on the pull request.