You're talking about adding six more methods to regexp.Regexp, which is already drowning in methods.
Especially since you can implement this easily with the closure (nice observation!),
I'm not sure it needs to be added to the standard library.

Is there any strong evidence that this sort of thing is needed?
(Examples: popular Go packages providing this as an add-on, evidence of widespread use in other languages, ...)

@rsc Yes it is easy to implement, like most of the "basic" functions. This can be seen as argument in both directions to add or to not add to the standard library.

My main argument is that this is a basic functionality present in most of the languages precisely because it is used very often.
My second argument is that the implementation is not a "one line code", even if it is easy to implement.

But I don't have "strong evidence that this is needed". Maybe somebody else can give such evidence ...

Adding to the proposal minutes for visibility.
We'd need to see more need beyond what is already there.

Perhaps a solution to consider could be adding one example to the doc showing the basic approach?

That said, there are already many examples in the package, so discoverability and overall noise level might be a concern.

For code like this, this issue itself can serve as a way to address the problem. I'm not sure it has to be in the package docs.

Based on the discussion above, this seems like a likely decline.

@rsc ok. Thanks for considering my request anyway.

Is there any strong evidence that this sort of thing is needed?
(Examples: popular Go packages providing this as an add-on, evidence of widespread use in other languages, ...)

I use the limit param in PHP all the time: https://www.php.net/manual/en/function.preg-replace.php

I am annoyed that I cannot use it in Go.

PHP contains much that Go does not.

(Also, if you are annoyed about needing this limit in Go frequently, I would suggest writing a function along the lines of the one at the top of this issue, and then you won't need to be annoyed anymore.)

I am just replying to "evidence of widespread use in other languages".
If you now answer "other languages have (much) more than Go", then I am not sure why you asked for evidence in the first place. (?)

Here is another example:
Python also has an easy and optional count argument for max number of replacements.
https://docs.python.org/3/library/re.html#module-contents

I can only report that we offer a template function in Hugo that supports a regexp replace with a maximum. We used the closure mentioned at the top of this issue.

I understand the argument against added a half-dozen functions to the package. So, I offer a compromise: change the ReplaceAll* function signatures in Go2 to add a n int parameter. The FindAll* functions already have a n parameter. It seems odd that the ReplaceAll* functions didn't follow suit. Can we fix this in Go2?

In effect there is no Go 2, there is just the possibility of regexp/v2. But that doesn't seem all that likely, as the regexp package is working fine.

Still, examples of cases where people would use limits are helpful. It might help to point to some places where people do use a limit, and why. That is, it does help to show other languages and frameworks that provide a limit. But it helps even more to show where people use that limit in their code. Thanks.

Use case example: in Hugo, we want to find to replace the first occurence of each glossary term on a given web page with a link to the definition in the Glossary. We do not want to link 100 occurrences of a word or acronym in an article.

My initial use case was similar to @fplanque's case : I wanted to replace only the first occurance in a program charged to convert from one file format to another.

Maybe at some point we should revisit the regexp API, but I don't think this incremental addition pulls its weight especially given the Func trick.

In retrospect the All form should have taken an n, like FindAll etc, but it's too late for that now.

No change in consensus, so declined.