On Thu, Mar 17, 2022 at 1:54 PM Henry Miller via SG14 <sg14@lists.isocpp.org> 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