LWG-2839 Self-move-assignment of library types, again #1485
Description
LWG-2839 "Self-move-assignment of library types, again" clarifies that move-assigning most Standard Library types to themselves leaves the object in a valid-but-unspecified state. While we are fairly fastidious about handling self-move and self-swap correctly when authoring new types, I'm not sure that our predecessors paid as much attention. We need to audit all of the move assignment operators in the STL to ensure that self-move leaves the class in a valid state except when the standard explicitly specifies otherwise.
Headers to Audit
-
<algorithm> -
<any> -
<array> -
<atomic> -
<barrier> -
<bit> -
<bitset> -
<charconv> -
<chrono> -
<codecvt> -
<compare> -
<complex> -
<concepts> -
<condition_variable> -
<coroutine> -
<deque> -
<exception> -
<execution> -
<expected> -
<filesystem> -
<flat_map>(not yet implemented inmain) -
<flat_set>(not yet implemented inmain) -
<format> -
<forward_list> -
<fstream> -
<functional> -
<future> -
<generator>(not yet implemented inmain) -
<initializer_list> -
<iomanip> -
<ios> -
<iosfwd> -
<iostream> -
<istream> -
<iterator> -
<latch> -
<limits> -
<list> -
<locale> -
<map> -
<mdspan> -
<memory> -
<memory_resource> -
<mutex> -
<new> -
<numbers> -
<numeric> -
<optional> -
<ostream> -
<print> -
<queue> -
<random> -
<ranges> -
<ratio> -
<regex> -
<scoped_allocator> -
<semaphore> -
<set> -
<shared_mutex> -
<source_location> -
<span> -
<spanstream> -
<sstream> -
<stack> -
<stacktrace> -
<stdexcept> -
<stdfloat> -
<stop_token> -
<streambuf> -
<string> -
<string_view> -
<strstream> -
<syncstream> -
<system_error> -
<thread> -
<tuple> -
<type_traits> -
<typeindex> -
<typeinfo> -
<unordered_map> -
<unordered_set> -
<utility> -
<valarray> -
<variant> -
<vector> -
<version>