What does it do if the value_type is not copyable?
Good question! Move can always fall back on copy, but there is no fallback for copy itself. The same goes for the default constructor. I think it would be best to not have the function available and adding a constant (is_constructable) for easy checking in both enable_if and if constexpr.

I'm also considering extending construct to support every valid constructor for that type through forwarding the parameters, but that may also cause confusion with rvalue parameters. A parameter that is moved into the first item will be empty when moved into the second item. But considering that these functions would mostly be used by library developers inside containers it would probably not be an issue.
A motivating use case, a paper and a demonstration of it providing real-world benefit might make it more convincing.
The motivating use case would be destructive move support by the standard library containers for types such as smart pointers. A bonus is putting the complexity of moving items around in a simple API.

I did not write any paper yet as the instructions per making a proposal is to first "float the idea". So, my question is more about if this idea is fundamentally broken or not, not if it should be directly added as it is now. And of course, feedback on any smaller corner cases (such as non-copyable) that I would have to figure out.

________________________________
From: Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf of Richard Hodges via Std-Proposals <std-proposals_at_[hidden]>
Sent: Monday, May 3, 2021 11:57
To: std-proposals_at_[hidden] <std-proposals_at_[hidden]>
Cc: Richard Hodges <hodges.r_at_[hidden]>
Subject: Re: [std-proposals] item_traits: A simple solution for destructive move



On Mon, 3 May 2021 at 11:22, Rick de Water via Std-Proposals <std-proposals_at_[hidden]<mailto: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);
};

It would of course have a non specialized version that works for all types and uses type_traits to determine the optimal way to move things around, and destructive_move would simply call move + destruct.

What does it do if the value_type is not copyable?


Are there any major issues with this idea that would prevent it from standardization?

A motivating use case, a paper and a demonstration of it providing real-world benefit might make it more convincing.

--
Std-Proposals mailing list
Std-Proposals_at_[hidden]<mailto:Std-Proposals_at_[hidden]>
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals