Thanks Arthur-
I'll put it to the committee at the meeting next week, but if anyone
here has any opinions about whether ==/!=/<=> is useful on the container
level (ordered or unordered), please chime in.
Given that the container (unlike unordered_map) is designed to be used
for iteration efficiently, it's not Quite the same but I take your point
about copies.
While a copy operator which copies out-of-sequence of the source is
possible, given the structure of the container I think it's unlikely, or
at least going to be always inefficient to copy out-of-sequence. That is
probably a good hint that an ordered == operator would make more sense,
if I'm following your reasoning?


On 15/03/2022 2:40 pm, Arthur O'Dwyer wrote:
> Another option to be considered is: you can provide *no* operator== at all.
> Compare to std::unordered_set<T>, which provides an *order-insensitive*
> operator== and *no* operator<=>.
> Compare to sg14::slot_map<T>, which provides *no* operator==.
>
> You need to decide whether order is /*salient*/. (Salient properties,
> such as vector::size, are compared by operator== and copied by the copy
> ctor. Non-salient properties, such as vector::capacity, are not.)
>
> One thing to consider is that copies are equal by definition.
> std::hive<T> a = { ... };
> std::hive<T> b = a;
> assert(a == b); // if operator== is provided at all, then this
> /*must*/ be true
> You mustn't ever provide an operator== that breaks this invariant. Maybe
> that greatly simplifies your decision, maybe it doesn't, I don't know.
>
> HTH,
> Arthur