<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hi,<div class=""><br class=""></div><div class="">About the bad old nonstandard RegExp functionalities:</div><div class=""><br class=""></div><div class=""><div class="">* `RegExp.prototype.compile()` — currently in Annex B;</div><div class="">* `RegExp.$1`, `RegExp.leftContext`, etc. — currently unspecced.</div></div><div class=""><br class=""></div><div class="">Although we could probably not get rid of them for plain regexps, I think it is a good idea to disable them for proper subclasses of RegExp (e.g., `class MyRegExp extends RegExp {}`).</div><div class=""><br class=""></div><div class="">Basically, the reason is that these methods break encapsulation (they operate on the raw regexp), leading to potential bugs when using them. Moreover `RegExp.$1` and friends have the additional troublesome property of relying on a global state that could be unexpectedly modified. For concrete examples of what could go wrong, see the subclass-restriction-motivation.md subpage in the proposal linked below.</div><div class=""><br class=""></div><div class="">Here is a link to a possible specification for the regexp statics (RegExp.$1, ...), that includes the disabling of bad legacy features for proper subclasses of RegExp (and for some edge-cases around cross-realm interactions):</div><div class=""><br class=""></div><div class="">     <a href="https://github.com/claudepache/es-regexp-legacy-static-properties" class="">https://github.com/claudepache/es-regexp-legacy-static-properties</a></div><div class=""><br class=""></div><div class="">What do you think? Are implementations willing to try?</div><div class=""><br class=""></div><div class="">—Claude</div><div class=""><br class=""></div></body></html>