You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I think it would be convenient to allow specifying a format for regex strings which include delimiters and flags, e.g., /abc/im. I presume this is not the current format, and I guess it would need a new format like delimited-regex (unless the lack of slash escaping were used to interpret this as a delimited regex rather than a failing regex).
I believe this format has the advantage of both being familiar (appearing as a regex literal) to users of ECMA-262 (the minimum regex dialect expected for support by format-processing implementations) and of being used in a similar manner in other regex dialects (e.g., PHP). This approach would not require mixing in non-ECMA-262 modifiers within ECMA-262 syntax.
Here is 7.3.8 of the Validation doc regarding the existing regex format--excerpted for convenience:
This attribute applies to string instances.
A regular expression, which SHOULD be valid according to the ECMA 262 regular expression dialect.
Implementations that validate formats MUST accept at least the subset of ECMA 262 defined in the Regular Expressions section of this specification, and SHOULD accept all valid ECMA 262 expressions.
If this approach was not desired, adding a flags or regexFlags property alongside format could also allow avoiding introducing non-ECMA-262 modifiers.
I might note FWIW that neither of these approaches are sufficient for a full serialization of regular expression objects in languages such as JavaScript (e.g., preserving its lastIndex property), but it would preserve the data, and allow for checks against, or UI reconstruction of, what is most likely to be of interest in portable storage of regular expressions.
The text was updated successfully, but these errors were encountered:
format is problematic and other solutions involving new keywords are preferred. Such new keywords are best discussed as possible 3rd-party extensions first, so moving this over to our holding area for such proposals.
handrews
transferred this issue from json-schema-org/json-schema-spec
Jun 25, 2020
Carrying over discussion from json-schema-org/json-schema-spec#821.
I think it would be convenient to allow specifying a
format
for regex strings which include delimiters and flags, e.g.,/abc/im
. I presume this is not the current format, and I guess it would need a new format likedelimited-regex
(unless the lack of slash escaping were used to interpret this as a delimited regex rather than a failing regex).I believe this format has the advantage of both being familiar (appearing as a regex literal) to users of ECMA-262 (the minimum regex dialect expected for support by
format
-processing implementations) and of being used in a similar manner in other regex dialects (e.g., PHP). This approach would not require mixing in non-ECMA-262 modifiers within ECMA-262 syntax.Here is 7.3.8 of the Validation doc regarding the existing
regex
format--excerpted for convenience:If this approach was not desired, adding a
flags
orregexFlags
property alongsideformat
could also allow avoiding introducing non-ECMA-262 modifiers.I might note FWIW that neither of these approaches are sufficient for a full serialization of regular expression objects in languages such as JavaScript (e.g., preserving its
lastIndex
property), but it would preserve the data, and allow for checks against, or UI reconstruction of, what is most likely to be of interest in portable storage of regular expressions.The text was updated successfully, but these errors were encountered: