Julien Blanc wrote: ...
* remove default construction and too short key construction for algorithms where this is actually harmful (such as siphash). I don't have an issue with providing constructors with keys for algorithms that do not mandate it. But boost code should encourage correct usage of the algorithms it propose, not allow bad usage in the name of genericity. ... * makes copy construction requirement on hash algorithm a requirement only if hash_append_unordered_range is used. Hashing unordeder ranges is an open problem, some creative other solutions may be found, and i see no reasons why they would involve duplicating the algorithm state. Actually, if the hash is default constructible, then it is not needed. You need either one of default or copy constructible, not both.
I already answered this (twice) - using default constructed hash algorithm instances in hash_append_unordered_range makes collisions seed-independent. But this aside, these two points also contradict each other. The first one wants to remove default construction from SipHash; the second one wants to use default construction in hash_append_unordered_range. If both are applied, SipHash will not work in hash_append_unordered_range. As for improving hash_append_unordered_range, my current ideas are here: https://lists.boost.org/Archives/boost/2024/12/258744.php