C++自定义容器移动语义下resize的移动后对象状态一致性问题

std::vector 提供的resize成员函数核心价值有两点：

• 合理场景下保留容器现有元素
• 非必要时不触发额外内存分配

这和直接执行 v = std::vector<T>(new_size); 的行为形成鲜明对比：后者既不保留原有元素，也无法避免不必要的内存分配。

目前标准库的resize仅提供接收左值引用的重载版本，调用形式为 v.resize(new_size)。
我正在实现一个逻辑与std::vector类似的自定义容器，计划新增右值感知版本的resize：调用该版本时传入的容器是右值，处于可被移动的状态，理论上无需保留原有元素，可以获得更高的执行效率——尤其是resize后的目标大小超过容器当前容量时，省略元素保留逻辑的性能收益尤为明显。我认为这个操作的设计是合法的，但不确定调用后容器应该满足什么样的一致最终状态。

基础测试示例代码如下：

my_vector<double> v(3, 42.);

std::move(v).resize(6);

核心疑问：上述代码执行后v应处于什么状态？哪种状态设计更符合C++现有的移动后对象设计哲学？

目前我梳理出4种候选状态：

1. v 共包含6个元素，所有元素的值完全未指定。
2. v 的元素为 {42., 42., 42., 0., 0., 0.}，与现有非右值感知版vector::resize的行为完全一致。
3. v 的前3个元素值未指定，后3个元素为默认构造值0.，即{unspecified, unspecified, unspecified, 0., 0., 0.}。
4. v 的6个元素均为默认构造值0.，即{0., 0., 0., 0., 0., 0.}。

我个人略微倾向于选项3。从实现角度看，选项4可能是选项3所定义的未指定行为下的常见非文档化实现结果；选项2虽然逻辑自洽，但从正式规范层面看，仅选项1、3是合理的候选方案。需要注意的是，当resize后的目标大小（如示例中的6）超过容器当前容量时，会触发内存重分配。

上述示例中使用double仅作为拷贝开销较高的非平凡类型的占位符，0.仅代表类型默认构造状态（T()），无特殊含义。对于传入填充值的resize重载版本，该问题同样成立，示例代码如下：

std::move(v).resize(6, 99.);

// 对应4种候选状态：
// 1. v共包含6个元素，所有元素的值完全未指定。
// 2. v的元素为 {42., 42., 42., 99., 99., 99.}
// 3. v的前3个元素值未指定，后3个元素为填充值99.
// 4. v的6个元素均为填充值99.

补充说明：无论最终采用哪种实现，std::move(v).resize(6);的性能都优于v = my_vector<T>(6)，因为后者必然触发新的内存分配，且会初始化所有元素。

内容的提问来源于stack exchange，提问作者alfC