[chii]

if you have an edge case you know you want, you could add the description into the input of the AI.

If you are afraid of unintended matches, that's a different problem, which you might also get writing the regex yourself!

The solution, i reckon, is to create (may be even via the same AI?) a large list of matches, and you manually look thru to see if there's unintended matches.

[carvking]

or just if clause it - why spend 1 hour chasing down regex to save yourself from writing 3 lines of code.

[eurasiantiger]

Because application performance matters more than developer performance.

[carvking]

This varies a lot.

Reading a 100mb file 10 times a day vs. 100 times a day is perfectly acceptable in many scenarios.

[eurasiantiger]

True, but in a fast-changing world, someone with slow data integrations might be leaving money on the table.

[episteme]

I thought Regex was typically less performant than string operations?

[eurasiantiger]

Depends. If you need to go through a 100MB file, you want to do it once, not twice.

[Banana699]

Depends very heavily on the task and the string implementation involved, but my prior is that you should always bet on regex for anything more complex than "ForEach chr in str: doSomething(chr)".

Modern regex implementations are their own language interpreters/compilers, they implement their own string data strutures, they compile your regex into specialized bytecode (different from the hosting language), they have tons of special cases checks for fast paths (e.g. capturing groups make regexes much much more complicated than they need to be, a regex without capturing has the option to run signficantly faster).

A random search just found out this 2016 SO question[1] where a compiled regex was faster than string.contains (!). Regex is just insanely optimized. It reminds me of C++, ugly and badly/un designed, but it can go fast.

[1] https://stackoverflow.com/questions/2962670/regex-ismatch-vs...

[Blackthorn]

Assuming you're using a non-backtracking library, they should both be O(n).