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

121–130 of 154 posts

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

#121

Post by kibwen »

cookiengineer wrote: post #74
kibwen wrote: post #59

Earlier quoted context omitted.

> semantic versioning allows "1.2.3alpha" and also 1.2.3-beta" No, according to the spec, the hyphen is mandatory: "A pre-release version MAY be denoted by appending a hyphen and a series of dot separated identifiers immediately following the patch version."

You interpreted your own copy/pasted answer wrongly. MAY has not the same meaning as MUST. MAY is optional, MUST is mandatory. > https://semver.org/#spec-item-9

No, that is a misreading. The "MAY" indicates that the prerelease identifier itself is optional. However, if you do append one, it must include a leading hyphen.

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

#122

Post by wongarsu »

tedunangst wrote: post #79
cookiengineer wrote: post #74

Earlier quoted context omitted.

You interpreted your own copy/pasted answer wrongly. MAY has not the same meaning as MUST. MAY is optional, MUST is mandatory. > https://semver.org/#spec-item-9

You may denote a prerelease version. Or not. But you can't just append any crap you like and call it the prerelease version.

The wording is ambiguous, but the BNF later in the spec [1] agrees with your interpretation. Valid version numbers are three numbers separated by dots, followed by either a minus and dot-separated pre-release versions; or a plus and dot-separated build identifiers.

1: https://semver.org/#backusnaur-form-grammar-for-valid-semver...

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

#124

Post by adonovan »

somekyle2 wrote: post #61
kevingadd wrote: post #7

Really bizarre. It seems like it wouldn't have been much more work to just implement it properly. Instead people are supposed to wait until the compiler magically gets smart enough to optimize the pattern... but the pattern and method are both intentionally slow, so there will never be usage pressure to optimize it. A reasonable compromise would be to just implement a single pass three-way compare in native Go instea…

It was previously implemented as a special internal function https://github.com/golang/go/commit/fd4dc91a96518fdbb47781f9... So, making it a simple Go function was more work (at least, as an individual change) because they could've left it. A three-way compare in native Go would likely be slower in most cases than the "slow" version that exists there, because in actually equal or size varying cases the "slow" one get…

I added the original fast implementation in this CL https://go.dev/cl/2828 because I found it useful, clear, and efficient in tuple "less" comparisons like this:

   if cmp := strings.Compare(x.first, y.first); cmp != 0 {
       return cmp
Compared to the != then < approach, it makes only a single pass over the string data. To this day I never understood the justification for intentionally making it slower, or why the style of code above isn't reasonable.

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

#126

Post by sltkr »

zenexer wrote: post #80
skybrian wrote: post #24

Earlier quoted context omitted.

The comment is confusing, but the idea seems to be that instead of calling this function, you should inline the code - that is, just write the comparisons yourself. You don't need a function call. I guess this is for stylistic reasons, but I don't know why anyone would feel strongly about doing it one way or the other.

I don’t think that’s true. I believe they want you to explicitly define how you want you compare strings. Comparing Unicode strings isn’t as straightforward as comparing individual bytes or code points. For example, there are multiple Unicode strings that will yield the character “ï”. If you use a naïve comparison function, you can’t be sure that it will behave as expected when it encounters the word “naïve”.

> I believe they want you to explicitly define how you want you compare strings.

If that were true, they wouldn't have made strings comparable in the first place, and they wouldn't recommend that callers inline the implementation (they'd recommend calling some locale-dependent function instead).

An explicit comparison like "naïve" == "naïve" or "naïve" how the comparison is performed than Compare("naïve", "naïve") would be.

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

#127

Post by Someone »

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.

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

#128

Post by gnfargbl »

Someone wrote: post #127

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

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

#129

Post by pjmlp »

vbezhenar wrote: post #116
pjmlp wrote: post #102

Earlier quoted context omitted.

Except Go certainly is never getting another major version, I am waiting for Go 1.10000.0, given how decisions are made on the ecosystem.

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.

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

#130

Post by seanw444 »

johndfsgdgdfg wrote: post #125

Well, it was desgined by Google. What did you expect?

Google generally engineers their stuff well. I don't like them much either, but calling them incompetent at building a very popular language, to which their reputation is attached and at risk, is rather presumptuous.
Post reply on HN