Normative: correct spec bug in RegExp.prototype[Symbol.matchAll]

[ljharb]

Filed on v8 as https://bugs.chromium.org/p/v8/issues/detail?id=9174, which it turns out matched the spec but not the intention/convention of the RegExp flags value.

[gsathya]

cc @schuay @peterwmwong PTAL

[ljharb]

This was a mistake on my part - https://tc39.github.io/ecma262/#sec-regexpinitialize has a special case for undefined being the empty string, and I overlooked that when ToStringing the flags value (in order to check if "g" is in it).

[zenparsing]

Do you think that @@split suffers from a similar issue?

var str = 'a\u{1d11e}b';
var pattern = /\u{1d11e}/u;
Object.defineProperty(pattern, 'flags', { value: undefined, configurable: true });
str.split(pattern);
// SyntaxError: Invalid flags supplied to RegExp constructor 'undefinedy'

undefinedy 🤣

[ljharb]

Yes, that also seems like the same spec bug to me.

I'd be happy to pursue changing this in the other methods too, if folks feel that's viable.

[rbuckton]

If we're going to do this in multiple places, should we have something like a ToStringOrEmpty operation to handle undefined (or null)?

BTW: null is an issue too, both for matchAll and split

[littledan]

I'm not convinced we should be adding defensive cases like this in subclassing built-ins. There remain lots of other silly things you can do to interfere with how things run.

[ljharb]

@littledan this isn't about subclassing; my example in the v8 bug is about a mutated base regex literal, and it follows the convention in new RegExp.

[littledan]

I know; I was using "subclassing" in the broad sense where this is all caused by "subclassable built-ins", the justification in ES6 to read flags here, rather than the internal slot. I don't see how this affects my point, though; we discussed this point several times in the development of matchAll.

[ljharb]

That was about people deleting things off of RegExp.prototype. This is about following existing conventions when reading flags off of an object, which are that undefined becomes the empty string, not the string “undefined”. If i were merely handling edge cases I’d want to do the same for null, but that’s not the convention so I’m not proposing that.

[littledan]

We discussed a case of deleting things off of RegExp.prototype in depth, but the underlying motivation (for me) was that we should not start being defensive against these things, in general--this was the design of ES6. The defensive design would be to just use internal slots for these things. I'd be in favor of returning to ES5-style RegExps, if it's web-compatible, but with the situation we have, I am not in favor of putting in lots of kinds of validation to avoid weird cases. There will be lots more weird cases, e.g., if flags returns something different from the individual getters, or if they return different values on subsequent calls.

[mathiasbynens]

(Posting here since Jordan asked)

The V8 team is not in favor of this patch. It enables even more esoteric RegExp subclassing behavior than is already possible today, and if accepted, would set precedent for similar changes.

Subclassing built-ins is an important use case, but in particular for RegExp the subclassing design is already pretty weird. We'd rather not add more complexity to support even stranger use cases, especially without them being driven by real-world use cases.