Question

最近，我讨论了C ++中表达式的赋值，如下例所示：

string s1, s2, s3;
(s1 + s2) = s3;

使用C ++ 11，可以将赋值运算符限制为左值引用（在左侧）。当声明赋值运算符如下时，由于类型不兼容，编译器Clang拒绝带有错误消息的代码。

auto operator=(const string& rhs) & -> string&;
auto operator=(string&& rhs) & -> string&;

我没有在任何地方见过这个。是否有充分的理由不为赋值运算符使用左值引用限定符（除了大多数编译器中缺少支持）？

Answer 1

有趣！我甚至都没有意识到这一点并带我去找它（它是"Extending move semantics to *this"提案的一部分）。符号在8.3.5 [dcl.decl]第4段中定义，以防任何人想要查看。

无论如何：现在，了解这个特性似乎最有用的是它用于重载，并且如果调用函数的对象是左值或右值，则可能表现不同。使用它来限制可以做的事情，例如，使用赋值的结果似乎是不必要的，特别是如果对象实际上恰好是左值。例如，您可能希望语法返回从赋值到右值的右值：

struct T {
    auto operator=(T&) & -> T&;
    auto operator=(T&&) & -> T&;
    auto operator=(T&) && -> T;
    auto operator=(T&&) && -> T;
};

这里的意图是从分配结果中移除（不管是否值得，但我不确定：为什么不首先跳过作业？）。我不认为我会主要使用此功能来限制使用。

就个人而言，我喜欢有时从rvalue获取左值的可能性，赋值运算符通常是一种方法。例如，如果您需要将左值传递给函数，但是您知道不想对它使用任何内容，则可以使用赋值运算符获取左值：

#include <vector>
void f(std::vector<int>&);
int main()
{
    f(std::vector<int>() = std::vector<int>(10));
}

这可能是滥用赋值运算符从rvalue获得左值，但不太可能偶然发生。因此，我不会通过限制赋值运算符仅适用于左值来使我的方式变得不可能。当然，将rvalue从赋值返回到rvalue也会阻止这种情况。如果有的话，这两种用途中的哪一种可能更有用。

BTW，clang似乎支持自2.9版以来引用的语法。

Answer 2

不，不是真的。使用左值或右值限定符为左值或右值对象构造正确的接口与使用const一样，并且应该以相同的方式接近 - 应该考虑每个函数的限制。对右值的赋值实际上没有意义，所以应该禁止它。

你没有看到它的原因是大多数糟糕的编译器支持 - *this的rvalue refs有点像thread_local，大多数编译器实现者似乎都把它放在了“功能”的底部。从C ++ 11“stack。

实现

Answer 3

我对你的建议不太热心的一个原因是I'm trying to shy away from declaring special members altogether。因此，我的大多数赋值运算符都被隐式声明，因此没有引用限定符。

当然，在我写一个类或类模板的时候，例如管理所有权（参见上面链接中的结论），我可以注意只为左值声明这些运算符。但是，由于它对客户没有任何影响，因此没有太大意义。