-
Notifications
You must be signed in to change notification settings - Fork 12
only finite sets of strings #26
Comments
I agree that it should be treated as separate.
It certainly can be useful; for example, we could have \p{valid_emoji} (or
some other syntax), which would match from the current position to the
first position that couldn't continue a valid emoji sequence. And set
combinations would make sense and be useful, such as
[\p{valid_emoji}--\p{RGI_emoji}], which matches emoji sequences that are
valid but not RGI.
|
I agree that named matchers for infinite sets of strings could be useful, but I'm not convinced this is part of the MVP. I would prefer pursuing it as a separate follow-up proposal. @waldemarhorwat, does that match your thinking? That said, here’s some thoughts:
Agreed.
Not sure I agree. I think we could totally use
I’m not sure. Mark’s example of |
Proposed resolution: There is enough reserved syntax (e.g., curly braces) to enable wide-ranging extensions in the future, but we don't plan to build something specific into the proposed spec changes. Cc stage 3 reviewers @waldemarhorwat @gibson042 @msaboff |
Intended for closing out issue #26.
In the TC39 meeting today (2021-may-26) there was some discussion of whether we should prepare for character classes matching infinite sets of strings.
From the start, the proposal has been to extended character classes, and supported Unicode properties, from finite sets of characters to finite sets of strings. This was the basis for the argument to use
\p
for properties of strings.As an example, in UTS #51 there is a very clear distinction between
It would be possible to support named matchers for infinite sets of strings, that is, a kind of named sub-regular-expression, but that is very different from a finite set, needs to have separate syntax, and should not be allowed inside character classes.
The text was updated successfully, but these errors were encountered: