On Fri, Mar 15, 2024 at 11:51 AM Ville Voutilainen <
ville.voutilainen_at_[hidden]> wrote:

> On Fri, 15 Mar 2024 at 15:12, Arthur O'Dwyer <arthur.j.odwyer_at_[hidden]>
> wrote:
>
> >> >> What is a user of P1144 expected to do about
> >> >> "pmr and allocator aware types will behave in
> >> >> surprising ways when used in containers and
> >> >> algorithms" ?
> >> >
> >> > The proof is in the pudding! Try to find me a "surprising" behavior
> of allocator-aware types. The complete implementation of P1144, one
> compiler and two standard libraries, is available for perusal.
> >> > - https://godbolt.org/z/eM8saKe6b
> >>
> >> I take that as a suggestion to stop spending time on P1144 and to
> >> focus all work on P2786 instead.
> >> I do not have time for reverse-engineering riddles.
> >
> >
> > And yet you have time to troll the SG14 mailing list.
>
> You aren't qualified to call other people's questions trolling.
>
> > Look, you made the claim. Please provide your evidence.
>
> What claim? I was quoting YOUR PAPER. A statement made in P2814R1.
>

That's a joint paper with the Bloomberg authors. You'd have to ask them.
I've already quoted you my own (less-than-15-page) summary of the key
differences between P1144 and P2786. Here it is again.

The major places where P2786R0 disagreed with P1144 are:

   -


   <https://quuxplusone.github.io/blog/2023/02/17/issaquah-status/#whether-std-swap-can-be-implemen>
   Whether std::swap can be implemented as “relocate A into a temporary;
   relocate B into A; relocate the temporary into B,” or whether it *must* be
   implemented in terms of assignment — and what “assignment” means for
   trivial types anyway. Vendors already optimize copy_n
   <https://godbolt.org/z/8nMoo6Tes> in a way detectable by the user; the
   question is if we should permit vendors to optimize swap
   <https://godbolt.org/z/Y5YMndM56> in the same way. P1144 says
   “optimize,” P2786 says “don’t.”
   -


   <https://quuxplusone.github.io/blog/2023/02/17/issaquah-status/#whether-vector-insert-can-use-re>
   Whether vector::insert can use relocation to “make a window” that is
   then filled with the new data (as in Folly’s fbvector
   <https://github.com/facebook/folly/blob/1d4690d0a3/folly/FBVector.h#L1273-L1292>),
   or whether it *must* be implemented in terms of assignment. P1144 says
   “optimize,” P2786 says “don’t.” See “Should assignment affect
   is_trivially_relocatable?”
   <https://quuxplusone.github.io/blog/2024/01/02/bsl-vector-erase/>
    (2024-01-02).
   -


   <https://quuxplusone.github.io/blog/2023/02/17/issaquah-status/#whether-a-type-containing-a-data>Whether
   a type containing a data member of type
   boost::interprocess::offset_ptr<T> may be explicitly warranted as
   [[trivially_relocatable]] (Godbolt <https://godbolt.org/z/hz56dqq4Y>).
   P1144 says “optimize,” P2786 says “don’t.”