We're not talking bleeding edge CS topics here mate, we're talking "hashability is a useful property because hashmaps", that was standard >25 years ago.
Java had hashCode in 1.0, GvR added __hash__ to Python in March 1993 and shipped it in 0.9.9.
Hash maps are 69 years old (nice). Bespoke key types (and thus the requirement for user-defined hash functions) is probably the more recent of the two.
So you don't understand what's happening here. They are not "hashing a structure", they are digging into internal implementation to reuse code that runtime uses to hash the structure.
> Java had hashCode in 1.0, GvR added __hash__ to Python in March 1993 and shipped it in 0.9.9.
is not doing that. It is just providing an interface that happens to be filled for builtin types
Also Go is not object oriented language and types don't have default set of methods returning things so having type.hash() like Java or Python would make no sense. Whether that's a good or bad call is another discussion but writing generic Hash[T] is few lines of code and would be just encoding/gob into hash of your choosing.
There is a case for providing that in function doing what the dolt guys are doing but that would be "just" optimization.
> So you don't understand what's happening here. They are not "hashing a structure", they are digging into internal implementation to reuse code that runtime uses to hash the structure.
Because Go does not expose the builtin hash function.
> is not doing that.
It's doing that without the feature existing.
> Also Go is not object oriented language
Which is not actually relevant, it clearly knows about "comparable" (which it also considers to mean "hashable"). It just refuses to expose that information.
> so having type.hash() like Java or Python would make no sense.
Are you wilfully picking at the tree's bark in order to avoid considering the forest for a single second?
> Whether that's a good or bad call is another discussion but writing generic Hash[T] is few lines of code and would be just encoding/gob into hash of your choosing.
And lose the benefit of the way the entire ecosystem works.
On the plus side, it would let you have keys with bespoke equality and hashing semantics, but that's clearly not what TFA is looking for.
It also can't be combined with go's own hashable because you can't involve either "comparable" or an interface with methods in a union, so there is no way to accept a "comparable|Hash" in order to leverage both.
And obviously by doing so you'd open the door to them being inconsistent. Which is also the point of using Go's own concept of hashability.
Java had hashCode in 1.0, GvR added __hash__ to Python in March 1993 and shipped it in 0.9.9.
Hash maps are 69 years old (nice). Bespoke key types (and thus the requirement for user-defined hash functions) is probably the more recent of the two.