implement Hash on tuples and owned containers

[thestinger]

This is definitely important for tuples (similar to how they implement Ord), but I think an IterBytes implementation would be strange, so they would probably have to use SipHash directly.

Hash can also be implemented for freezable containers like vectors, maps and sets. In Python this is a very common idiom and they actually have a frozenset type for this use case, and it's the main reason Python has tuples (which in Python are just immutable lists).

Ideally there would be one implementation of combining hashes and it can be reused. I'm not entirely sure how such a thing would be implemented correctly though.

[catamorphism]

Nominating to change milestone to 5 (production-ready).

[thestinger]

I don't think this is actually milestone-worthy.

[huonw]

Triage, no change.

Similar issues #9075, #8038.

[pnkfelix]

Just some notes (which I'm sure the current participants are already aware of, this is more for general reviewers):

• We do already implement IterBytes on a large set of tuple types (see std::to_bytes). This may not be as satisfying as providing a generic implementation for all possible tuple types, but we do not really have the capability to express that yet. (The latter is related to the variadic generics RFC: RFC: variadic generics #10124)
• We also provide IterBytes for &[A] and ~[A], but not for other containers. We do not yet have a container trait that provides a way to iterate over all of the container's contents, so presumably the implicit goal here is to have the built-in containers (like HashMap, HashSet and TrieMap) implement IterBytes, but utilizing @thestinger's hypothesized method for combining hashes. (Maybe the stuff in libcollections too, not sure.) Or maybe I misunderstand the goal here.

[Gankra]

I think this is just done, right? They're all hashable now, I believe.

[ghost]

@gankro I think you're right. Closing.