Joaquin M López Muñoz wrote:
El 18/05/2025 a las 19:29, Ivan Matek escribió:
On Sun, May 18, 2025 at 5:59 PM Joaquin M López Muñoz via Boost <boost@lists.boost.org> wrote:
I don't know, looks to me ugly and potentially confusing to users, who have no real use for that.
To be honest I do not think it is so bad, you could just document it is a common "primitive" used when it comes to index computation, and then users will know why it is where it is. Only thing I suggest is to not put it in core. I have seen core/util/common/whatever_name bloat in many projects and I am not a fan of that.
In fact, there's another piece of functionality that I'd rather have migrated to ContainerHash, namely the is_avalanching trait. Currently this lives in Boost.Unordered, which forces Boost.Bloom to depend on it for no other reason than to access this almost trivial utility --not ideal, obviously.
I would be a big fan philosophically of trait being in a small header/library. For related example I dislike that for iterator_tags you must include heavy std header, when it is trivial functionality. IIRC there are even Boost libs that are defining them just to get around the include. :)
Boost.IsAvalanching? Not sure I'm buying that :-)
I already have to declare hash_is_avalanching in ContainerHash https://github.com/boostorg/container_hash/blob/b8179488b20eb1373bdbf5c7fcca... so I have no objections to moving it there. IIRC we originally kept in in Unordered because Unordered was C++11 and ContainerHash wasn't yet. But now it is.