> On May 19, 2016, at 11:21 AM, Claude Pache <[email protected]> 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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
