Descriptive Problem Summary:
When using a global regex, calling Find(str,1) works as normal the first time, but the implementation defaults to using src.next any subsequent search on the same string, effectively making passing a start position for a regex find pointless UNLESS you are searching a new string.
This is a little misleading, as I expected that passing a start position, even with the same string, would reset the value of next.
Currently, this means that using a global regex, we need to reset regex.next to 1 after each search if we plan to use it in a position where we're not sure whether the same value will be used a second time. There are not many situations we can expect to know that this will not happen.
ID:2885674
 Aug 20 2023, 7:58 pm
|
|||||||||||||
| |||||||||||||
findtext() and its variants are always compiled with the correct number of arguments, which means defaults get filled in by the compiler. This is obviously a problem when it comes to determining the intent of a call to findtext() where the start position was omitted. (And regex.Find() is defined under stddef.dm as just a call to findtext() where start and end are passed explicitly, with start defaulting to 1.)
So it looks like the resolution to this lies in 516, where I can version-gate a behavior change to compile findtext() differently and to interpret it differently, allowing true nulls as the start and end positions so that it's now possible to tell if they were given explicitly as numbers or not.
For now, there are two workarounds for global regexes (that is, regexes with the "g" flag): The first was mentioned above, which is setting regex.next = 1 after each find. The second is to set regex.text to a different string (an empty string should do), since any change to that will also reset the global search.