Yeah, all the talk of replacement seems like people masively overthinking or abstracting a day one problem. My C++ solution was a simple search using the <algorithm> header. It's a little less neatly abstracted out as yours, and could be cleaned up a fair bit, as I wasn't bothered to deduplicate the code after getting it working (and I will if this turns out to be useful tomorrow), but the essence is the same:

https://gist.github.com/joedavis/3d6f2b87bae4809ef8a062caff7...

C++'s .rbegin() / .rend() reverse iterators made the search fairly trivial.

I disagree on it being "overthinking". I just did replacement without really thinking. Saw that it failed on the "eightwo" case since "two" got replaced first, so just replaced "two" with "two2two" instead, then passed it through solver for part1. To me that's simpler and more naive than correctly writing a search or backwards-forwards regex :)

My solution in Kotlin https://github.com/kolonialno/adventofcode/commit/686cbebb07...

Ahh, people are trying to do a replacement before finding tokens. I wondered why so many people were saying this was difficult. My head went straight to token parsing, which given the limited set of tokens made it trivial. Thought I was missing something

I think people with understanding of compilers always want to model their code as DSL, and that makes it easier to go for backwards scanning.

>replacement-strategy

Oh so THAT is what is causing people problems.