On 04/05/2021 20.30, Arthur O'Dwyer via Std-Proposals wrote:
On Mon, May 3, 2021 at 5:22 AM Rick de Water via Std-Proposals <std-proposals@lists.isocpp.org> 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).

That is very sad to hear, my code could certainly use the proposal. But I'm not desperate enough to use a patched compiler (the vanilla version is plenty broken already).