c++ - 为什么 std::string append 不会在 rval ref 上重载？

Question

我很熟悉，append 中的 std::string 返回 std::string&，因此它没有资格从中移动，因此不会移动结果。

#include <string>


int main()
{
    std::string s = std::string("A").append("B");
    return s.size();
}

https://godbolt.org/z/M63aWW

#include <string>


int main()
{
    std::string s = std::move(std::string("A").append("B"));
    return s.size();
}

https://godbolt.org/z/jTnsac
在那里你可以看到，后一个例子将产生一个更少的分配，因此在这种情况下，最好移动一些看起来像临时的东西。我的问题是为什么他们(委员会)不在 && 上添加简单的重载来根据上下文使 append 的结果成为 std::string& 或 std::string&& ？我的意思是类似于 std::optional 正在做的事情 value 。有没有一个例子可以证明这种优化是假的？

Answer 1

正如P1165R1所涵盖的那样，basic_string的operator+的分配器传播规则很复杂，并且是不同库实现之间不一致的根源。

Make stateful allocator propagation more consistent for operator+(basic_string)

[...] Allocator propagation for basic_string’s operator+ is haphazard, inconsistent, and a source of implementation divergence. Let's make them consistent. [...]

P1165R1 已被 C++20 接受。 append() 成员函数没有相同的语义，没有像 operator+(P1165R1 之前)那样的重载和“偶然性……”。前者没有理由加入后者的领域； basic_string 已经是一个容器的怪物(这不是你的反例 optional 的情况，它不是标准意义上的容器，即使它具有类似于 STL 容器的语义)。