After exploring things further, we have come up with a revised parsing behavior that does not require prefix operators containing / to be banned, and fixes all the case path compatibility issues we have previously seen.
The changes are twofold:
-
When encountering a prefix operator containing
/, we will not parse a regex literal if there is no closing/delimiter on the same line. This is the same behavior as with unapplied infix operators. -
The
)heuristic has been expanded such that the entire range of the regex literal is scanned for an unbalanced). If such a case is encountered, we will not parse a regex literal. This takes both escapes and custom character classes into consideration.
Together, these changes mean that many uses of prefix / will be unaffected by the introduction of regex literals. It also means that ambiguities can be readily disambiguated with parentheses, for example
foo(/x, y / z) can be disambiguated as foo((/x), y / z) due to the expanded ) heuristic.