The comment in the code explains why not

I'm aware of that comment. But I think it should be optimized, as many projects use the function often.

@seankhliao please reopen this issue.

Many projects writing poor code doesn't mean we should optimize it, especially when we're actively trying to discourage it.

Such code in many projects is not poor at all.

If you think they are poor, please show the not-poor way.

The comment explicitly says that we don't want to encourage people to use strings.Compare. That hasn't changed. We expect code to compare strings using operators like == and <. Those are the cases that we should optimize (in the compiler), not the strings.Compare function. (And if we do optimize those cases in the compiler, then perhaps strings.Compare will be optimized too as a side-effect.)

I understand this. But there are situations in which strings.Compare should be used and the strings.Compare is expected to be implemented performantly.

In other words, I don't think the comment is reasonable.

bytes.Compare has made the optimization, so I think it is easy for strings.Compare too.

More specifically, there are many uses cases shown in https://sourcegraph.com/search?q=context:global+switch+strings.Compare+lang:Go+&patternType=literal are like:

func foo(x, y string) {
	switch strings.Compare(x, y) {
	case -1:
		// do something 1
	case 0:
		// do something 2
	case 1:
		// do something 3
	}
}

I think this is a common use case.

Instead of worrying about strings.Compare, let's make this efficient. If we do that strings.Compare will become more efficient as a side-effect.

func foo(x, y string) {
    switch {
    case x < y:
        // do something 1
    case x == y:
        // do something 2
    default:
        // do something 3
    }
}

So for some cases, even if the operator way is not efficient, it is still recommended to use this way, by making the other way also inefficient deliberately?

I would say, instead, focus on making the more readable approach efficient. Don't focus on making the less readable approach efficient. We aren't making strings.Compare deliberately inefficient; we're making it the same as the more readable approach.

Readability might be a subjective word. Personally, I don't think there is a readability difference between the two ways.

The two ways are not overlapped fully. There are situations in which using strings.Compare (assumed it is implemented normally as expected) is more efficient, and there are also situations in which using operators is more efficient. I really don't understand why to deliberately prefer one to the other.

And personally, the role of recommending the operator way to the strings.Compare way for some situations is go vet, instead of the standard packages.

And the third, the current docs of the strings.Compare doesn't mentioned the current implementation is slower than expected for some situations.

One advantage of the strings.Compare way is the case order has much less impact on the performance, but the case order in the operator way impacts the performance much.

I will close this issue, for I found a similar one: #31187

But I think close the issue for using strings.Compare is poor code or less-readable code is not acceptable.

OK, it is closed already.

Some notes:

• the strings.Compare function is used in toolchain code: https://github.com/golang/go/blob/go1.19/src/cmd/go/internal/modindex/read.go#L822
• and this function is recommended by sort.Find: https://github.com/golang/go/blob/go1.19/src/sort/search.go#L88-L99

Some conflict with the internal comment of strings.Compare: Basically no one should use strings.Compare.

BTW, there are more uses of this function out of switch blocks: https://sourcegraph.com/search?q=context:global+strings.Compare+lang:Go&patternType=standard