Daniel James wrote:
On 19 December 2017 at 15:48, Peter Dimov via Boost
wrote: If we name the module 'hash' it's not hard to see that in the future it will be seen as the obvious home for implementations of MD5, SHA-*, and other hash algorithms (FNV-1a, cityhash...) which we do miss in Boost. So there will be pressure to add them, pull requests implementing them, and so on.
The question is do we see this as a bad thing?
Well I don't want this to create extra pressure on me, so I do. I'd rather they were separate, unless we were expanding the boost::hash implementation to support multiple hash algorithms.
After looking into this a bit, I think that it would be hard to expand our current boost::hash in a compatible manner, due to the way it's specified - boost::hash<X>()(x) is required to call hash_value(x), which is probably implemented by the user in terms of hash_combine, which in turn is required to call back to boost::hash<T>, and boost::hash can be specialized, so everything is detectable and has to work in precisely this manner. It would probably be best to proceed as planned with the extraction of functional/hash as-is into its own 'hash' module and leave the future extensible framework separate (we could imaginatively name its module 'hash2'.)