When I look at https://go.godbolt.org/z/8jqMPh135, compiling for a few CPUs, recent compilers only generate a single call to runtime.cmpstring.
⇒ I think the comment is outdated, and there is a safe efficient way to do three-way string comparisons in go.
Caveat: I’m not that good at reading modern assembly, and I do not understand why there also is a call to runtime.memequal in that code. ⇒ Corrections welcome.
I'm not that good at it either, but I think that the runtime.memequal call is coming from the if a == b test, and that it is the if a < b test that is being replaced with a call to runtime.cmpstring.
If so, then I guess there's still a redundant call to runtime.memequal inserted by the compiler.
It's hard to imagine any of this matters at all, in practice, which is probably why the go authors haven't bothered addressing the issue.
Thanks! Never thought == could be a simple buffer comparison (after a length check, I guess). I thought locale and things being Unicode would make that harder.
Ah, this confuses everyone: strings in Golang are really just read-only byte slices. They can contain Unicode, but they don't have to, and the == operator just does a byte comparison.
⇒ I think the comment is outdated, and there is a safe efficient way to do three-way string comparisons in go.
Caveat: I’m not that good at reading modern assembly, and I do not understand why there also is a call to runtime.memequal in that code. ⇒ Corrections welcome.