Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

No safe efficient ways to do three-way string comparisons in Go

go101.org

Post reply on HN
Print view View original

151–154 of 154 posts

Re: No safe efficient ways to do three-way string comparisons in Go

#151

Post by yencabulator »

saghm wrote: post #49
barsonme wrote: post #45

Earlier quoted context omitted.

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.

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 mai…

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.

Re: No safe efficient ways to do three-way string comparisons in Go

#152

Post by saghm »

yencabulator wrote: post #151
saghm wrote: post #49

Earlier quoted context omitted.

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 mai…

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.

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.

Re: No safe efficient ways to do three-way string comparisons in Go

#153

Post by yencabulator »

saghm wrote: post #152
yencabulator wrote: post #151

Earlier quoted context omitted.

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.

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.

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 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.

Re: No safe efficient ways to do three-way string comparisons in Go

#154

Post by etse »

pjmlp wrote: post #129
vbezhenar wrote: post #116

Earlier quoted context omitted.

What's wrong with Go 2 with tools to automate migrations? Of course that limits the scale of possible changes, but moving methods between packages should be possible with this approach.

Community culture, most likely it will never happen as such.

Change doesn’t have to come at the pace of npm. Let’s be charitable, people. :)
Post reply on HN