The ability to transfer allocated memory between std::vector,
std::string, and other contiguous container/string types was discussed
in LEWG and SG16 back in 2018 in the context of P1072
(basic_string::resize_and_overwrite) <https://wg21.link/p1072>. No
consensus for a design emerged at that time but I think a well
researched paper that includes motivation based on real world use cases
would have a good chance of being adopted. Any such paper would ideally
compare and contrast the proposed design with the existing node handle
support added for associative containers in C++17 (I tend to think of
std::vector and std::string as being single-node containers; which
differs from other random-access containers like std::deque).

Tom.

On 12/22/23 11:15 AM, ஜெய்கணேஷ் குமரன் via Std-Proposals wrote:
> Hello all,
>
> At the moment there appeärs to be no way to create a std::vector or std::string from an existing memory buffer, or take ownership of the memory owned by std::vector or std::string.
> This is very limiting in interoperability scenarios where you may not be able to expose a std::vector or std::string directly.
>
> Technically, a custom allocator could be used that provides existing memory but still the actual objects cannot are not considered.
>
> I propose having .attach and .detach member functions on std::vector and std::string.
> They should take in or return the following respectively, in a structure perhaps: pointer to the data (.data), count of the elements (.size/length), capacity of the buffer (.capacity) and the allocator instance.
>
> Note: I do not have the time to participate in standardisation in order to open formal proposals, but I wish someöne else does based on my ideas.
>
> Thanks,
> Jaiganésh Kumaran.