On Thu, Mar 17, 2022 at 1:54 PM Henry Miller via SG14 <sg14_at_[hidden]>
wrote:

> On Thu, Mar 17, 2022, at 03:00, Matthew Bentley via SG14 wrote:
>
> > * I think it should probably be specified that copying a container
> > Cannot change the iteration order. There is no legitimate performance
> > reason not to specify this (as far as I know), as iterative order is
> > also memory locality order, hence iterative order is also the fastest
> > way to copy. This also makes the copying of sort()'ed hives less
> > problematic. If anyone has any objections to this let me know.
>
> I'm not convinced. If there are a lot of memory blocks, [...]
> To make the above optimizations (or others not thought of yet) possible I
> think order after copy should be unspecified for now. At this time I don't
> see any harm in leaving iteration order unspecified after copy, and it may
> (or may not) be useful. Or to put it differently, what is the gain to
> making the iteration order specified - hive is an unordered container so
> user code shouldn't rely on any order, and if std:: itself relies on order
> the implementation is free to add a restriction not in the standard.
>

FWIW, I'm sympathetic to Henry's argument. But on the other hand, this
again comes down to what properties are salient and what properties are not.

    std::hive<int> a = {1,2,3,4,5};
    a.sort();
    assert(std::is_sorted(a.begin(), a.end()));
    auto b = a;
    // Copies are substitutable. Every salient property of `a` is now a
property of `b`.
    // Is sortedness salient? Or can it be "lost" simply by copying the
object?
    assert(std::is_sorted(b.begin(), b.end())); // ???

Arthur