Fallible replace_all for regular expressions

Yes, there are broader challenges here indeed. API design is hard, and it's often much harder to know what to leave out than to what to leave in. I don't have any hard evidence that fallible replaces are not exotic for example. I just have a guess that the vast majority of folks needing replacements do not need a fallible closure.

Exacerbating this issue is the fact that there are three different replacement routines: replace, replacen and replace_all. So does adding a try variant meant we need three more replacement routines? That starts to clutter up the API. Maybe we could just get away with try_replacen, but in my experience folks will continue to ask for the other two methods as well.

How much of a problem this is IMO depends on what you're saving by providing more APIs or more complicated APIs. If it were saving something that was impossible or extremely difficult to implement on your own, then the case for adding fallible replacement routines strengthens. But that's just not the case here. The thing being saved is a few lines of code that are just not that hard to write. So instead of forcing the ~99% use case to pay the API tax of more complexity, I chose to force the ~1% of the population to pay the implementation tax to write their own code.

I am generally willing to revisit these decisions as new evidence or arguments appear. Otherwise, it just really boils down to a judgment call.