While we are in a time period where additions to standard function library can actually happen, I'd like to propose several string functions to bridge some gaps in compatibility with common APIs:
string_pos_ext(substr, string, start)
Much akin to regular string_pos, but with a specifiable offset to start search from.
Mirrors the behaviour of optional second parameter in indexOf in common APIs.
Other option would be to add an optional parameter to string_pos, but I think having a separate function would create less confusion (considering that Pascal-style argument order in string_pos already makes some).
Current workarounds:
Finds the position of last occurrence of substr in string.
Mirrors the behaviour of lastIndexOf in common APIs.
Current workarounds:
Finds the position of last occurrence of substr in string, only searching until `end` position.
Mirrors the behaviour of optional parameter version of lastIndexOf in common APIs.
Current workarounds:
While all of these functions are trivial to implement (indexOf\lastIndexOf on JS, offset search for string_pos_ext on native, string::rfind for string_lastpos on native), they are priceless for parsers and other algorithms involving searching for consequent patterns in strings.
string_pos_ext(substr, string, start)
Much akin to regular string_pos, but with a specifiable offset to start search from.
Mirrors the behaviour of optional second parameter in indexOf in common APIs.
Other option would be to add an optional parameter to string_pos, but I think having a separate function would create less confusion (considering that Pascal-style argument order in string_pos already makes some).
Current workarounds:
- string_pos(substr, string_delete(string, 1, start - 1)) + (start - 1)
Easy to implement, but not viable on larger strings due to allocating one string per search (since GM does not optimize substrings like JS does). - Custom search via a for-loop with string_char_at\string_copy comparisons.
Not viable on large strings due to use of UTF-8 as format for string storage (meaning that string_char_at(_, N) is actually O(N) instead of O(1)). - Custom search via a "fast" buffer.
Somewhat viable on large strings, but only if the algorithm is complex enough to justify longer setup time (string->fixed buffer->fast buffer).
Finds the position of last occurrence of substr in string.
Mirrors the behaviour of lastIndexOf in common APIs.
Current workarounds:
- Series of string_pos + string_delete calls to find the last occurrence.
As mentioned above, not a good solution, except here the effect is even worse due to doing this a number of times in a row. - Custom search via a "fast" buffer.
Same as above; Using string-based backwards search usually isn't viable even on average-sized strings.
Finds the position of last occurrence of substr in string, only searching until `end` position.
Mirrors the behaviour of optional parameter version of lastIndexOf in common APIs.
Current workarounds:
- Same as for string_lastpos, except with slightly more overhead.
While all of these functions are trivial to implement (indexOf\lastIndexOf on JS, offset search for string_pos_ext on native, string::rfind for string_lastpos on native), they are priceless for parsers and other algorithms involving searching for consequent patterns in strings.