On Tue, 14 Apr 2026 at 17:54, Robert Baumgartner via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> 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
> static initialization order fiasco
> <https://en.cppreference.com/w/cpp/language/siof.html>. constexpr objects
> cannot be accidentally used before initialization,
> 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,
>

The standard library already has constexpr sort.



> duplicate detection, and open addressing hash table are non-trivial to
> implement correctly. The proposed solution makes this
> accessible behind a familiar interface.
>
>