If there is a vet check , it would make sense to start by only handling cases when the number of arguments is locally known.

_ = strings.NewReplacer("a", "b", "c")

or

list := []string{"lorem ipsum"}
_ = strings.NewReplacer(list...)

Does this really merit a vet warning? strings.NewReplacer already panics at run-time with a pretty clear error message (https://play.golang.org/p/bUQg60lQCJZ), so having any test coverage at all for the call would uncover the bug when the number of arguments is easy to determine.

It seems like this check would be most useful when strings.NewReplacer is called with a non-trivial slice obtained from somewhere else, but those cases are also much more difficult for a vet analyzer to find.

The main check will be on the variadic argument case. My preliminary study of some code base indicates the following common patterns:

var r []string
for i := 0; i <= k; i++ {
    r = append(r, something)
}
strings.NewReplacer(r...)

and

var r []string
for i := range m {
     r = append(r, something)
 }
strings.NewReplacer(r...)

where "k" and "m" usually come from function arguments. To make it work we will need to reason about "k" and the size of "m" through inter-procedural analysis, which is probably out of the scope of vet.

This seems too specialized and with too little benefit.

It is also not clear if the pattern described by @guodongli-google satisfies the requirement of high enough frequency.

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

Based on the discussion above, this proposal seems like a likely decline.
— rsc for the proposal review group

Can't comment since the primary reason for this issue is the parameter type.

No change in consensus, so declined.
— rsc for the proposal review group