On Mon, May 3, 2021 at 5:22 AM Rick de Water via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> When working on a container library I needed to manage the complexity of
> moving items around (memcpy when trivial, noexcept or not, copy if not
> movable, etc), and I came up with a traits class that manages everything
> for you. You give it a destination pointer, and often a source pointer, and
> the traits class will do the rest.
>
> This is already very useful to have, but then I realized that it could
> also easily do a destructive move. By specializing the traits class for a
> destructively movable item (like unique_ptr) it can optimally move the
> items from the source to the destination memory. All container classes can
> then simply use item_traits to move items around whenever needed.
>
> Here is a simplification of my current implementation:
> template <typename Item>
> struct item_traits
> {
> using value_type = Item;
> using pointer = value_type*;
> using const_pointer = const value_type*;
> using size_type = std::size_t;
>
> static void construct(pointer destination, size_type size);
> static void destruct(pointer destination, size_type size);
> static void copy(pointer destination, const_pointer source, size_type
> size);
> static void move(pointer destination, pointer source, size_type size);
> static void destructive_move(pointer destination, pointer source,
> size_type size);
> };
>

Are you familiar with the existing STL free functions for these operations?
std::construct_at(T*, Args...)
std::destroy_at(T*)
std::uninitialized_default_construct(T* first, T* last);
std::destroy(T*, T*)
std::uninitialized_copy(T*, T*, T*);
std::uninitialized_move(T*, T*, T*);

Are you familiar with P1144 "Object relocation in terms of move+destroy"?
It adds:
std::relocate_at(T*, T*);
std::uninitialized_relocate(T*, T*, T*);

P1144 is stationary in the water at the moment; I've got a draft D1144R6 at
http://quuxplusone.github.io/draft/d1144-object-relocation.html
but I don't see it going anywhere at WG21 without compiler vendor buy-in,
and I don't see it going anywhere with compiler vendors without WG21 buy-in.
What it really needs is for someone *in industry* to start using my patched
version of Clang+libc++, visible at
https://p1144.godbolt.org/z/nxdWGxj5M
and maintained on my GitHub; and then crowing about how cool it is (or,
perhaps, realizing it's not so cool — we simply don't know yet because
nobody's really tried it out).

–Arthur