4 ms·
I’d argue that any string comparison which does not take into account collation is inherently broken. Even in the pure ASCII English-language case, a naïve comp
by dhosek 4y ago
I’d argue that any string comparison which does not take into account collation is inherently broken. Even in the pure ASCII English-language case, a naïve comparison on values won’t give desirable results since abc123 will come before abc99 even though a reader would expect otherwise. Just because we’ve tolerated crappy string sorting for sixty years doesn’t mean we should continue to do so.
- eru 4y agoFor some applications (eg sticking stuff in an ordered data structure), you just need any consistent ordering, but don't care too much about exactly which one.
- codedokode 4y agoThen you can use bytewise comparison instead of alphabetic comparison.
- snotrockets 4y agoAssuming you normalized the strings before.
- simiones 4y agoWhy would that matter, if you only want some well-defined order?
- snotrockets 4y agoBecause with (Unicode) strings, "\u006e\u0303" is defined to be equal to "\u00f1", for example. If you'd do bytewise comparison, as the above comment suggested, you may not reach the same result ¯\_(ツ)_/¯
- simiones 4y agoWhether those two strings are or are not equivalent depends on the context. If we're assuming (as the GP did) a very generic context where we simply want to store arbitrary strings in a sorted data structure, then there is no reason to assume they are supposed to be interpreted as Unicode. For a simple example, perhaps this is a list of strings that require Unicode normalization to be properly interpreted as human text that you are storing into a TreeMap for efficient retrieval. When you are adding "\u00f1" to the list, you wouldn't want the collection to say that it's already there because it already had "\u006e\u0303".
- cookiengineer 4y agoI've been developing my own version string parser for a couple weeks now, in golang. It's ridiculous to what lengths you have to go to understand which part of a string comes earlier or later. Simple example: semantic versioning allows "1.2.3alpha" and also 1.2.3-beta", but which one comes first now... - Is 1.2.3 > 1.2.3omega? - Is 1.2.3 > 1.2.3beta? - Is 1.2.3gamma > 1.2.3? In the Linux world it gets even funnier cause they invented SONAME fields that reflect breaking API changes instead of forcing packages to comply with semantic versioning syntax. Oftentimes there is a package version of e.g. 0.4.7 that has an SONAME of 12.7 on the filesystem. Add to that the ~prerelease suffix syntax in Debian based distros which are maintained downstream, and all the +buildid or .commithash or -revision123 suffixes and you've landed in string comparison hell. When I started I would have never guessed that this is such a complex problem to solve in golang.
- oefrha 4y agoYes, version string comparison is hard because people have all sorts of unstandardized ideas about version strings. Not sure why you seem to believe there’s golang-specific difficulty here.
- kibwen 4y ago> 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."
- cookiengineer 4y agoYou 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 https://semver.org/#spec-item-9
- tedunangst 4y agoYou may denote a prerelease version. Or not. But you can't just append any crap you like and call it the prerelease version.
- dhosek 4y agoThen in that case, treat the string as an array of bytes.