I dont see how using []rune will avoid the duplicate characters in cutset issues as the user now may as well define duplicate elements in []rune. In addition []rune has the downside of not being a 1 to 1 replacement of the old function signature and has larger storage requirements and is not constant.

I dont think Strip conveys a meaning that it is a cutset more or less then Trim so I dont think just advising to use Strip instead of Trim makes developers more or less likely to mistake the function as not using a cutset.

@martisch I edit the issue again to focus on 1 suggestion. Thanks.

Presumably if we do something in the strings package we would also it in the bytes package.

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

If we make a change here, we should also change the names to not use "left" and "right". We should use "prefix" and "suffix" instead.

The open question is how often this comes up and the vet check (#46533, not implemented yet) wouldn't catch it for people.

We have strings.IndexAny(s, chars) already. Maybe

TrimAny
TrimPrefixAny
TrimSuffixAny

We should probably also do

TrimPrefixFunc
TrimSuffixFunc

instead of TrimLeftFunc, TrimRightFunc.

It would be a good test of "go fix"-based inlining (does not exist yet) to migrate these. We might want to wait for a coherent migration story.

Let's put this on hold until we have the migration story better understood, and then we can return to this. It seems worth doing with the names we chose, as a test of the migration tool if nothing else.

Placed on hold.
— rsc for the proposal review group