proposal: strings: add new functions to deprecate strings.{Trim/TrimRight/TrimLeft} to avoid mistakes

[hitzhangjie]

Hi, could we add new methods to solve the problem of cutset type in Strings.{Trim/TrimRight/TrimLeft}.

Apparently, many gohpers misunderstood the this cutset type, and it cauese some bugs. And, there're several proposals for solving the cutset type problem:

• cmd/vet: report strings.Trim/TrimLeft/TrimRight with duplicate runes in cutset #46533
• proposal: cmd/vet warns when the cutset of strings.{Trim,TrimLeft,TrimRight} is not in order #47822

I read through this proposals and see the conclusion is no change will be made.

This cutset problem affects many developers:

• if we have known the problem already, we may not make the same mistake again.
• but if we doesn't know it in advance, we may likely make the mistake.

In python, str.{strip/rstrip/lstrip}('cutset') method works the same as in go strings.{Trim/TrimRight/TrimLeft}(s, "cutset"). Maybe this signature is ok.

If we:

• add new methods strings.{TrimCutset\TrimRightCutset\TrimLeftCutset}, and add //Deprecated and go:linkname on strings.{Trim/TrimRight/TrimLeft}, we may make this clearer
• or add new methods strings.{TrimCutset\TrimRightCutset\TrimLeftCutset}, and declare the cutset as []rune, and use this methods to reimplement strings.{Trim/TrimRight/TrimLeft}

[martisch]

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.

[hitzhangjie]

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

[ianlancetaylor]

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

[rsc]

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

[ianlancetaylor]

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.

[rsc]

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.

[rsc]

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.

[rsc]

Placed on hold.
— rsc for the proposal review group