Resending, as the previous mail did not include the mailing list.

> Can't you do this in C++26?
> constexpr std::unordered_set<E> set({x, y, z});

As of the current status of C++26 both std::unordered_set and
std::unordered_map do not support constexpr.

> And if you don't want it to be constant, use constinit so that it's
guaranteed to be initialized at compile time
> (avoiding the static init order fiasco) but can still be modified later.

Using constinit as an interim solution is a sensible proposition. The main
differentiators between the two proposals are:

1. The unordered_set still lacks the cache-friendliness through pointer
chasing. For the proposed use case its performance
would carry an overhead of at least one additional pointer access.
2. It lacks the constexpr semantics and cannot be used in meta-programming.

> The standard library already has constexpr sort.

Still O(log(n)) lookup time.

Am Mi., 15. Apr. 2026 um 19:40 Uhr schrieb Jonathan Wakely <cxx_at_[hidden]>:

>
>
> 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.
>>
>>