bytes/hash: rename to hash/maphash

[rsc]

The implementation landed for #28322, which is great (thanks!).
The choice of bytes/hash as the import path is probably not right.

Based on the discussion on #28322, it's not completely clear it will
stay limited to bytes for all time. Even if it did, it is unclear why it is
bytes/hash and not hash/bytes. Neither is great, since the package
name alone shadows either bytes or hash. As it is, the current
bytes/hash.Hash implements (non-bytes/)hash.Hash, which is
pretty confusing. Goimports won't know what to do for hash.Hash
anymore, and so on.

It seems like it should be either in package hash, with a clear name
(hash.Seeded? hash.Random?),
or else in a hash/something package with a clear name.

/cc @randall77 @bradfitz @alandonovan

[randall77]

We sort of settled on a byte stream API, so bytes/hash seemed reasonable. Maybe hash/stream?

The hashes in hash are all explicitly spec'd hashes, which this really isn't. Thus I don't think it should just be another type in hash.

[rsc]

The fact that it's not spec'ed and can't escape the current program seems like the most important property, not the "stream" part. All hashes are streams. Maybe hash.Local or hash.Private or hash.Unspecified or hash.InMemory or hash.Undefined or ...
Just not hash.Fast.

[bcmills]

(Just bikeshedding, feel free to ignore.)

• hash.Builtin?
• hash.Runtime?

[alandonovan]

Not Runtime -- we don't guarantee it's the same one used by Go maps.

If Fast is a bad name because it draws users to it like magpies to a shiny thing, then Unspecified is a good name.

[OneOfOne]

hash.Memory? imho Unspecified sounds "scary" to a point, specially if you're coming from C/C++.

[rsc]

unspecified is such a long name to type.

hash/unspec
unspec.New
unspec.Hash
unspec.Seed

better ideas?

[rsc]

or hash/maphash?

// Package maphash implements a fast, randomly seeded, collision-resistant hash function
// for use in implementing hash table-based maps. The exact algorithm is unspecified and
// may vary from implementation to implementation. The random seeds make it impossible to
// depend on (or attack) the details of the algorithm anyway.

[josharian]

Short: hash.Mem, hash.Go (or hash/memhash, hash/gohash)

[rsc]

It looks like there is a strong consensus for hash/maphash. Let's go with that.

[gopherbot]

Change https://golang.org/cl/204997 mentions this issue: hash/maphash: move bytes/hash to hash/maphash