4 ms·

Go doesn't have many features of other languages. There are several competing goals, including keeping the language small, not hiding complexity, etc. Manually

Go doesn't have many features of other languages. There are several competing goals, including keeping the language small, not hiding complexity, etc. Manually writing the three-way comparison fits in with these goals. If slices were comparable then I'd wager that bytes.Compare would not exist.

saghm 4y ago
What sticks out to me is the part saying "the compiler should be changed". It's weird enough that this isn't even a doc comment but a comment inside the function (making it harder for people using the function to notice), but even as someone who thinks the passive voice is often unfairly maligned, the phrasing immediately brings to mind the question "who should change the compiler?" Is the Go standard library not maintained by the same group of people as the compiler, or is this comment just a doubly obfuscated "TODO"?
- yencabulator 4y ago
  It's not a TODO yet, it 's a note that says if you think this would be a good idea, do that instead. It's a potential TODO-to-be, waiting for the need.
  - saghm 4y ago
    Is that better? That would mean that they have a method in their API that they don't think anyone should use but haven't deprecated it or documented it that way and have no plans to do anything about it.
    - yencabulator 4y ago
      strings.Compare is mostly used in trivial demonstration programs, and is there because bytes.Compare is there. It makes https://pkg.go.dev/sort#Find https://pkg.go.dev/sort#Find documentation simpler. Deprecating strings.Compare would make sort documentation worse. Real code tends to not be that trivial, and that's why real code most likely shouldn't be using strings.Compare.
thayne 4y ago
Even if the compiler had good optimization of three way compares, this would be useful for passing to a higher order function. Say a function that allows you to specify how strings should be ordered.

saghm 4y ago

What sticks out to me is the part saying "the compiler should be changed". It's weird enough that this isn't even a doc comment but a comment inside the function (making it harder for people using the function to notice), but even as someone who thinks the passive voice is often unfairly maligned, the phrasing immediately brings to mind the question "who should change the compiler?" Is the Go standard library not maintained by the same group of people as the compiler, or is this comment just a doubly obfuscated "TODO"?

yencabulator 4y ago
It's not a TODO yet, it 's a note that says if you think this would be a good idea, do that instead. It's a potential TODO-to-be, waiting for the need.
- saghm 4y ago
  Is that better? That would mean that they have a method in their API that they don't think anyone should use but haven't deprecated it or documented it that way and have no plans to do anything about it.
  - yencabulator 4y ago
    strings.Compare is mostly used in trivial demonstration programs, and is there because bytes.Compare is there. It makes https://pkg.go.dev/sort#Find https://pkg.go.dev/sort#Find documentation simpler. Deprecating strings.Compare would make sort documentation worse. Real code tends to not be that trivial, and that's why real code most likely shouldn't be using strings.Compare.

thayne 4y ago

Even if the compiler had good optimization of three way compares, this would be useful for passing to a higher order function. Say a function that allows you to specify how strings should be ordered.