Just as a followup, I presented the arguments for-and-against as have been
discussed here to LEWG, LEWG voted against retaining ==, so that, != and
<=> will be removed from the spec-
Thanks for the discussion!
M

On Mon, 21 Mar 2022 at 09:35, Matt Bentley <mattreecebentley_at_[hidden]>
wrote:

> Basically, hive/colony is sorted until emplace/insert/splice are called.
> No other functions with the exception of swap/operator = (for the
> destination)/~hive affect this.
> In practice, operator = will always preserve order - I doubt that an
> implementation would spawn threads to process operator =, or that there
> would be a significant performance advantage to doing so outside of
> non-trivially-copyable types, though I suppose it's possible.
> However, the 'just in case' argument is worth pursuing.
> There is probably less potential harm in not specifying it than in
> specifying it.
>
>
> On 18/03/2022 8:08 am, Arthur O'Dwyer via SG14 wrote:
> > On Thu, Mar 17, 2022 at 2:34 PM Henry Miller via SG14
> > <sg14_at_[hidden] <mailto:sg14_at_[hidden]>> wrote:
> >
> > On Thu, Mar 17, 2022, at 13:19, Arthur O'Dwyer wrote:
> > >
> > > 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())); // ???
> >
> > That is a good point, though it may better make the argument that
> > hive [should not be] sortable. While the implementation allows
> > sort, that seems like an accident of implementation, the intended
> > use cases is a set of items that you need to iterate quickly without
> > concern for order. std::unordered_set is not sortable.
> >
> >
> > A std::unordered_set cannot be sorted /in its entirety/ without breaking
> > its hash invariant; although I suppose one could imagine sorting each
> > bucket individually, and the STL's unordered_set doesn't actually permit
> > that. (It does expose the buckets via `.begin(x)` and the local_iterator
> > API, but it doesn't let you manipulate the buckets themselves in the
> > same way you can manipulate, say, a std::list.)
> >
> > The better analogy here would be sg14::slot_map. Philippe Groarke has
> > thought a lot about the "special skills" of slot_map, although it was
> > years ago now:
> > https://github.com/WG21-SG14/SG14/issues/147
> > <https://github.com/WG21-SG14/SG14/issues/147>
> > https://github.com/WG21-SG14/SG14/issues/131
> > <https://github.com/WG21-SG14/SG14/issues/131>
> > https://github.com/WG21-SG14/SG14/pull/133
> > <https://github.com/WG21-SG14/SG14/pull/133>
> > Order-of-elements in general /*is*/ a salient property for
> > sg14::slot_map: it's preserved by copying. This includes sortedness,
> > partitionedness, even heapness. However, sg14::slot_map doesn't actually
> > support those "special skills" today; there's an old unmerged pull
> > request (from me) for .partition() but I never thought about .sort() or
> > .reverse() or .make_heap() or .next_permutation() or .rotate() or any
> > other ordering verb in particular.
> >
> > Note that immediately after x.sort(), the container /is sorted/; but
> > since the elements' values are mutable, you can't assume that it'll
> > /stay/ sorted for long. So we can't play any too-clever tricks such as
> > keeping track of an "is_sorted" flag and having copy do different things
> > depending on whether the container is_sorted or not. Either
> > order-of-elements in general is salient, or it's not.
> > https://godbolt.org/z/r9fx1s411 <https://godbolt.org/z/r9fx1s411>
> >
> > –Arthur
> >
> > _______________________________________________
> > SG14 mailing list
> > SG14_at_[hidden]
> > https://lists.isocpp.org/mailman/listinfo.cgi/sg14
>