Looking at it briefly, I'd say that a throwing move-only type couldn't be put into a vector otherwise, but maybe it shouldn't?
I believe you've nicely summed up the choices the committee had for containers of move-only-noexcept(false)-types.
- Allow them but with basic exception safety instead of strong for some operations.
- Disallow them at compile time.
A. The committee absolutely felt that they could not silently change existing C++03 code from having the strong exception safety to having basic exception safety.
B. For those functions that have strong exception safety, the committee much preferred to have those members continue to have strong exception safety, even for code that could not possibly be written yet (e.g. for functions manipulating move-only types).
The committee realized it could accomplish both of the objectives above, except for the case in B) where the move-only type might throw during move construction. These cases are limited to a few member functions of vector
IIRC: push_back
, reserve
. Note that other members of vector
already offer only basic exception safety (even in C++98/03), e.g.: assignment, insert (unless inserting at the end), erase.
With all this in mind, it was the committee's decision that should the client create a vector
of a move-only-noexcept(false)-type, it would be more useful to the client to relax the strong exception safety to basic (as it already is for other vector members), rather than to refuse to compile.
This would only be new code that the client writes for C++11, not legacy code, since move-only types do not exist prior to C++11. And no doubt the educators of C++11 should be encouraging their students to write noexcept(true) move members. However code with the basic exception safety guarantee is not so dangerous, nor unusual, such that it should be forbidden. After all, the std::lib is already chock full of code carrying only the basic exception safety guarantee.