Peter Dimov wrote:
It doesn't matter. The choice is between documented algorithms and undocumented algorithms, not between the specific algorithms I specified and something else. I argue that the algorithms need to be documented.
Well, the algorithms are documented. They're in your proposal. I didn't put them in my documentation because I was worried that if I changed them in the future (and I don't mean the near future, I'm going to be very cautious about such changes), that there would be complaints because I'd changed from what was in my documentation. But I have changed my mind on this (as I mentioned earlier). Although, I'm still not sure if it's appropriate to fully specify the functions for integers.
Yes, the reason that this came up, is because this wasn't true for Jeremy's original implementation. But I think his hash function for strings was faster, which might be desirable. [snip] That said, I don't see why this is an argument in favor of making hash_range return something else. The whole point of providing hash_range is to allow the user to write a hash function for their custom string (or container) type that returns the same result as the standard hash function for strings (or other containers).
It wasn't, I was just trying to give some background on discussions that had happened off list.