std::move_if_no except 仍然移动抛出仅移动类型的基本原理？

move_if_noexcept http://en.cppreference.com/w/cpp/utility/move_if_noexcept will:

• 返回一个右值——促进移动——如果移动构造函数是noexcept 或者如果没有复制构造函数（仅移动类型）
• 返回一个左值——强制复制——否则

我发现这相当令人惊讶，因为具有投掷 move-ctor 的仅移动类型仍然会由使用以下代码调用此 move-ctormove_if_noexcept.

对此是否有充分的理由？ （也许直接或在字里行间N2983 http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2983.html?)

不编译代码比仍然面临不可恢复的移动场景不是更好吗？这vectorN2983 中给出的例子很好：

void reserve(size_type n)
{
  ... ...
                 new ((void*)(new_begin + i)) value_type( std::move_if_noexcept( (*this)[i]) ) );
        }
        catch(...)
        {
            while (i > 0)                 // clean up new elements
               (new_begin + --i)->~value_type();

            this->deallocate( new_begin );    // release storage
            throw;
        }
*!*     // -------- irreversible mutation starts here -----------
        this->deallocate( this->begin_ );
        this->begin_ = new_begin;
        ... ...

标记行中给出的注释实际上是错误的 - 对于可以引发移动构造的仅移动类型，当我们将旧元素移动到新位置时，可能会失败的不可逆突变实际上已经开始了。

简单地看一下，我会说投掷仅移动类型不能放入向量中，否则，但也许不应该？

简单地看一下，我会说仅投掷移动类型不能 否则可以放入向量中，但也许不应该？

我相信您已经很好地总结了委员会对仅移动 noexcept(false) 类型的容器的选择。

1. 允许它们，但有基本的异常安全性，而不是某些操作的强安全性。
2. 在编译时禁止它们。

答：委员会绝对认为他们不能默默地将现有的 C++03 代码从具有强异常安全性更改为具有基本异常安全性。

B. 对于那些具有强异常安全性的函数，委员会更倾向于让这些成员继续具有强异常安全性，即使对于尚不可能编写的代码（例如，对于操作仅移动类型的函数）。

委员会意识到它可以实现上述两个目标，但 B) 中的情况除外，即仅移动类型可能会在移动构造期间抛出异常。这些情况仅限于以下几个成员函数vector IIRC: push_back, reserve。请注意，其他成员vector已经只提供基本的异常安全（即使在 C++98/03 中也是如此），例如：赋值、插入（除非在末尾插入）、擦除。

考虑到所有这些，委员会决定客户是否应该创建一个vector对于 move-only-noexcept(false) 类型，对于客户端来说，将强异常安全性放宽到基本（就像其他向量成员已经这样）会更有用，而不是拒绝编译。

这只是客户端为 C++11 编写的新代码，而不是遗留代码，因为在 C++11 之前不存在仅移动类型。毫无疑问，C++11 的教育者应该鼓励他们的学生编写 noexcept(true) move 成员。然而，具有基本异常安全保证的代码并没有那么危险，也没有那么不寻常，以至于应该被禁止。毕竟，std::lib 已经充满了仅包含基本异常安全保证的代码。