Design
Backing Store
keyed_set is implemented as a thin adaptor over
std::set<Value, value_compare, Allocator>. The internal
comparator —value_compare— wraps the user-supplied
Compare via private inheritance for empty-base optimisation, and
applies it to v.*Key rather than to Value directly.
key_compare vs value_compare
keyed_set follows the std::map model:
key_compareis the user-suppliedCompare, operating onkey_type. Returned bykey_comp().value_compareis the internal projecting adaptor, operating onvalue_type. Returned byvalue_comp().
is_transparent and Heterogeneous Lookup
value_compare always defines is_transparent so
that std::set activates its heterogeneous tree operations, which
are required because std::set::key_type is Value while
our key_type is the projected member type.
The template overloads accepting an arbitrary K are
conditionally enabled via
requires requires { typename Compare::is_transparent; } on both
the comparator and all heterogeneous lookup functions. A non-transparent
Compare supports only key_type lookups; a transparent
one supports arbitrary comparable types.
Non-Type Template Parameter
Key is declared as auto Key rather than
auto Value::*Key. The latter syntax is not supported by all
C++23-capable compilers (GCC < 14 rejects it).
from_range and insert_range
These are guarded by __cpp_lib_ranges_to_container and delegate
to the iterator-range constructor and insert(first, last) rather
than to std::set's own from_range constructor, which
may be absent even when std::from_range_t is defined.
Why No multi_keyed_set
A multi_keyed_set would allow multiple objects with the same key,
contradicting the container's fundamental semantic: the key is intrinsic to the
value, so duplicate keys represent a data integrity error. A grouping by a
non-unique attribute is a different abstraction and is not provided here.


