RegExp.firstMatch should have a start argument

[Hixie]

I want to try a bunch of patterns from one start index, then try them all again from the end position of the first match, if there was a match, until I get to the point where there are no matches.

The only way to do this right now is to use allMatches with a start index and then see if the result has any values and if so return the first one. This is rather awkward.

It would be cleaner if I could just use "firstMatch" with a start index. (For completeness, hasMatch and matchString also should have a start argument.)

Note that "matchAsPrefix" has a start index argument, but that doesn't help because it implies an anchored match at the start of the pattern. This would only work if the patterns all started with .*?, which they don't.

[lrhn]

All methods taking a string should also take start and end parameters to allow the function to work on a substring. It seems to me that that's the way they are all turning out after a while anyway.

Alternatively we should make it cheap to create a substring, so you wouldn't worry about doing it and passing the substring to the function.

I think the latter will give us better APIs in the long run.

[lrhn]

Are you sure you don't want to use matchAsPrefix repeatedly at increasing start positions?

If you try your patterns until you find a match, and the matching is allowed to search, you won't necessarily find the earliest match in the string first.

E.g., if you search for the patterns "a" and "bb" in the string "cbbbbacbbba" by trying the patterns in order until you find a match, then you will find two as and no bbs.
If you use matchAsPrefix with both patterns first at first position 0, then position 1, etc., until you find a match, then you will find the earliest match in the string.

[Hixie]

I ended up doing something quite different (I use allMatches for all the patterns and then verify there are no overlapping matches). I agree that the algorithm I initially described is bogus. I still think it's weird that you can't say "find the first match for this pattern after this point", though. :-)

[lrhn]

You can use use allMatches(pattern, start).first. The implementation of allMatches should be lazy so it only finds the first match. Less convenient, as you write, but doable.

[Hixie]

Sure but then why do we have firstMatch at all?

[lrhn]

Good point. We only have it on RegExp, not on Pattern (Pattern is a small interface because String has to implement it too), so it should be possible to add a start position.
Or, even better, add a Match firstMatch(Pattern p, [int start]) on String (which is actually easier because nobody else is implementing the String type, so we won't break them by changing the interface).

[Hixie]

We should move these APIs from using an index to indicate the start to using an iterator or whatever solution we come up with for #28404.

[jonpittock]

Just bumped into this. The suggestions dont account for empty matches. So the code ends up looking like:

    final Iterable<RegExpMatch> iterable = pattern.allMatches(source, start);
    final RegExpMatch? match = iterable.isEmpty ? null : iterable.first;

Which is pretty gnarly.

[lrhn]

As usual, adding an extra parameter to the RegExp interface is a breaking change, in case someone implements the interface.

Can use something like:

extension PatternFirstMatch on Pattern {
  Match? firstMatch(String source, [int start = 0]) =>
      pattern.allMatches(source, start).firstOrNull;
}

This adds a firstMatch to all patterns, except RegExp which already has one, but you can call it on the RegExp anyway by upcasting to Pattern, (re as Pattern).firstMatch(string, start).

(Would still be nice to update the RegExp method, it's just so much harder because it's breaking. I'm really sorry we couldn't make RegExp a final class, it should have been one.)