On 4/14/26 18:53, Robert Baumgartner wrote:
>> What doesn't work, for your use-case, using each of these approaches?
>
> frozen -> no guaranteed interface, no standard availability, adds an external dependency. The standard library should
> provide guaranteed portable solutions without external dependencies.

So, why don't we just standardize "frozen" or something similar?

Having a "constexpr" replacement for GNU gperf (perfect hash
function calculation) seems to be exactly what constant evaluation
was made for.

> The primary design
> would use open addressing with collision handling, just like a runtime std::unordered_set.
> O(1) at runtime is guaranteed through immutability of the array, hence fixed load factor.

Not really. If you have a fixed non-cryptographic hash function,
I think it's practical to construct a set of keys that will cause
so many collisions that nobody would call that O(1). A decade ago
or so, people noticed that hashes are vulnerable to such targeted
attacks, causing a denial-of-service vector for Internet-facing
services that put user-supplied data into hash tables.

Jens