This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of New status.
Section: 23.1 [strings.general] Status: New Submitter: Jonathan Wakely Opened: 2015-06-26 Last modified: 2020-09-06
Priority: 4
View all other issues in [strings.general].
View all issues with New status.
Discussion:
The allocator-aware container requirements in Table 98 impose no MoveAssignable requirements on the value_type when propagate_on_container_move_assignment is true, because typically the container's storage would be moved by just exchanging some pointers.
However for a basic_string using the small string optimization move assignment may need to assign individual characters into the small string buffer, even when the allocator propagates. The only requirement on the char-like objects stored in a basic_string are that they are non-array POD types and Destructible, which means that a POD type with a deleted move assignment operator should be usable in a basic_string, despite it being impossible to move assign:#include <string> struct odd_pod { odd_pod() = default; odd_pod& operator=(odd_pod&&) = delete; }; static_assert(std::is_pod<odd_pod>::value, "POD"); int main() { using S = std::basic_string<odd_pod>; S s; s = S{}; // fails }
Using libstdc++ basic_string<odd_pod> cannot even be default-constructed because the constructor attempts to assign the null terminator to the first element of the small string buffer.
Similar problems exist with POD types with a deleted default constructor. I believe that basic_string should require its value_type to be at least DefaultConstructible and MoveAssignable.[2016-06, Oulu]
This should be resolved by P0178
Note: P0178 was sent back to LEWG in Oulu.
Proposed resolution: