There are several Boost-related projects underway around the theme of unordered containers (in my case, I'm pretty much on the verge of releasing a preview of hashed indices for Boost.MultiIndex.) All these projects have the common need of a hash<> implementation being available, preferrably promoted to a public namespace rather than as an implementation detail.

Agreed.

Although Boost.TR1's purpose is not to implement new features but rather wrap them to achieve std::tr1-compliance, I think it'd be very useful if some tr1-hash implementation could be added to Boost. For the record, I'm currently using Jeremy Maitin-Shepard and Daniel James' implementation in Sanbox files/unordered.tar.gz. I think it is a rather solid implementation, taking care of compilers witohut PTS such as MSVC++ 6.0/7.0.

Yes, I would also like to see that added - it really just needs some docs - there's not that much to review given that the design is fixed by the TR.

As for the location, my pereference would be boost/functional/hash.hpp. Boost.TR1 could embrace this later in boost/tr1/functional.hpp.

Could this be done? Maybe as a separate activity from Boost.TR1? Am I entitled to do it myself as part of the upgrade of my library, even though this would be adding a new library in disguise? As it happens, I think I'll be able to release hashed indices in time for Boost 1.33, but this detail can be a showstopper :(

Personally if your just talking about adding boost::hash<> (and not all the containers as well), then I would be inclined to suggest that you go ahead, although it might be better to place it (temporarily) either in detail, or under the pending sub-directories, since it hasn't been reviewed etc. Otherwise we might end up with another aligned_storage style clash at some point (although a TR-conforming version should always take preference). Anyone else want to throw in their thoughts? What's the timescale on the unordered container development, how much is there left to do? John.