Thank you for the detailed feedback — let me address each point.
> Well, if the values are known at compile-time, I'd expect that you initialize the
> unordered_set during process startup (as global initialization), so this overhead
> doesn't appear during execution.
> The run-time overhead you do have with std::unordered_set is the pointer-based data
> structure, which is likely to cause quite a bit of cache footprint.
You are right to say that this can be a global object, but this introduces other problems, e.g. the
hence removing a class of bugs altogether. The proposed structure works fundamentally different,
giving compile time initialization, i.e. much stronger guarantees on when initialization happens.
Additionally ultra-low latency users, who want as few cycles as possible, will benefit both from zero-initialization
as well as from removing the pointer based data access, which as you already stated has an implicit penalty
by being less cache friendly.
> Feel free to define a constexpr or consteval helper function that
> initializes the array appropriately, and ensures duplicates are
> flagged or ignored.
Even if I did so and I sorted my array, lookup will still remain at O(log(n)), as opposed to O(1) of a proper
hash set data structure.
But
on top of that it also pushes complexity onto every user needing this
pattern. The standard library exists to provide correct,
efficient, reusable implementations of common patterns so engineers don't have to reimplement them. A constexpr sort helper,