The `RegExp.prototype.global` getter algorithm in 21.2.5.4 contains:
3. If R does not have an [[OriginalFlags]] internal slot throw a TypeError exception.
This means that the following code should throw, since `R = RegExp.prototype` in that case, and `RegExp.prototype` does not have [[OriginalFlags]] internal slot:
RegExp.prototype.global
However, none of the existing major ECMAScript engines seem to implement this, and instead return `false`.
The same goes for the following other getters on `RegExp.prototype`: `ignoreCase`, `multiline`, `sticky`, and `unicode` (although that last one is not implemented anywhere yet).
Please consider removing this step from those algorithms to match existing implementations.
Note that this also (indirectly) affects whether accessing `RegExp.prototype.flags` directly throws or returns `''`.
I don't see how this is any different from `RegExp.prototype.exec()` throwing a TypeError in ES6, whereas in ES5 (= major ECMAScript engines) it returns `[""]`. Adding special case code in everyplace to handle this breaking change is non-constructive (IMHO), simply going back to specify that RegExp.prototype is RegExp object almost seems to be the better choice...
The same issue applies to Date.prototype, Array.prototype, String.prototype etc.
When we decided to make RegExp.prototype a non RegExp instance we talked about these edge cases and IIRC then these new exceptions are what we want.
(In reply to Erik Arvidsson from comment #3)
> When we decided to make RegExp.prototype a non RegExp instance we talked
> about these edge cases and IIRC then these new exceptions are what we want.
Right, the only places we have reverted from this approach has been situations where we could actually identify code in the wild that depended upon the prototypes of legacy built-ins behaving as actual instances.
Mathias are you aware of any such situations WRT RegExp.prototype?
(In reply to Allen Wirfs-Brock from comment #4)
> (In reply to Erik Arvidsson from comment #3)
> > When we decided to make RegExp.prototype a non RegExp instance we talked
> > about these edge cases and IIRC then these new exceptions are what we want.
>
> Right, the only places we have reverted from this approach has been
> situations where we could actually identify code in the wild that depended
> upon the prototypes of legacy built-ins behaving as actual instances.
>
> Mathias are you aware of any such situations WRT RegExp.prototype?
No.
closing as invalid
The current spec. reflects what TC39 discussed