Should RegExp(regexp, flags) always return a functional RegExp for reasonable values of flags?

Allen Wirfs-Brock allen at wirfs-brock.com
Thu May 19 21:12:24 UTC 2016


> On May 19, 2016, at 11:21 AM, Claude Pache <claude.pache at gmail.com> wrote:
> 
> Hi,
> 
> Given a RegExp object `rx` and a string `f` that contains legal RegExp flag characters, should ideally the following expressions
> 
> ```js
> RegExp(rx, f)
```
This will throw a syntax error if rx is a non-u RegExp object that uses syntax that is invalid in in a u-regexp and f; includes “u”.  Note that this form of the constructor rx.[[OriginalSource]]  as the source that is parsed (using the f flags). See https://tc39.github.io/ecma262/#sec-regexp-pattern-flags <https://tc39.github.io/ecma262/#sec-regexp-pattern-flags> 

```js
> eval("/" + rx.source + "/" + f)
> ```


As current spec’d this may or may not throw a syntax error depending upon the implementation.  See https://tc39.github.io/ecma262/#sec-escaperegexppattern <https://tc39.github.io/ecma262/#sec-escaperegexppattern> . The text that is returned is derived from rx.[[OriginalSource]] but in addition to added certain required escapes, the spec. text seems to allow deleting redundant escapes.

> always return a functional regex?

If either returns (rather than throwing the returned regexp must be functional.
> 
> Practical example: `rx = /\-/`, and `f === "u"` (recall that `\-` is invalid in u-regexps but valid in non-u-regexes).

throws using the constructor, may or may not throw using rx.source and eval
> 
> One may wish that `RegExp(/\-/, "u")` and `eval("/" + /\-/.source + "/u")` be both equivalent to `/-/u`.
 
The construct or definitely is not.

> Context: That question came up while I was thinking about a possible precise specification for `RegEx.prototype.source`.

This may be an unintentional spec. over-site.  Note that once upon a time, input was that implementation did not want to change their implementation depended escaping. Perhaps things are different now.

Allen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20160519/4816cd80/attachment.html>


More information about the es-discuss mailing list