STL 容器的右值引用限定符

Question

为什么元素访问STL容器的成员函数，例如std::array::operator[] 或 std::vector::operator[] 没有右值引用限定符重载？我当然可以 std::move(generate_vector()[10])，但我很好奇在标准化引用限定符时是否考虑添加右值引用限定符重载。

我认为std::array<T, N>和std::tuple<T, T, ..., T>真的是一回事，后者的"element access function (i.e., std::get)"对于const vs non-const和lvalue vs rvalue的所有组合都是重载的。为什么不是前者？

将右值引用限定的元素访问成员函数（return 右值引用）添加到我的自定义容器是个好主意吗？

编辑

Richard Critten 的评论。我认为这偶尔会有用。

例如，您有一个函数，return是在该函数内部构造的容器，但您可能只对该容器的第一个元素感兴趣。是的，这很愚蠢。在这种情况下，使用只构造第一个元素的更简单的函数肯定更好。但是如果这个功能不是你的，你就没有这个选择了。

或者，可能有更一般的例子。您有一个构造容器的函数，您希望处理该容器以获得另一个结果。例如，您可能希望对该容器执行 std::reduce 或 std::unique_copy。（似乎在执行 std::reduce 期间禁止修改元素，但让我们假设我们已经实现了允许修改的元素。）在这种情况下，可以使用 std::make_move_iterator，但为什么不让容器本身 returns 移动迭代器？

编辑2

事实上，我在向容器 class 实施一些 "view" class 时遇到了这个问题。可变视图（左值引用）、不可变视图（常量引用）和可移动视图（右值引用）似乎都是必需的，我必须从可移动视图的元素访问成员函数中确定要return什么class：左值或右值引用？我觉得有点奇怪，return 对容器本身不公开此类接口的元素的右值引用。哪一个是正确的？

左值引用。
右值引用。
移动视图，总的来说，是不对的。这种东西应该不会经常用到，应该是我的设计有什么严重的问题吧。

Answer 1

将 ref-qualifiers 添加到 returns 引用的所有内容并没有特别的问题，但是这基本上使成员数量增加了一倍，除了包装 return 在 std::move.

class A
{
    int a;

    int& operator[](std::size_t pos) & { return a; }
    int&& operator[](std::size_t pos) && { return std::move(a); }
};

标准库拒绝提供这些重载，就像它拒绝提供许多 volatile 重载一样。在这种情况下，您可以在需要的地方 std::move & 值。

如果您正在编写自己的容器，那么没有安全性 避免此类重载的理由。它确实增加了维护负担，所以我建议不要这样做。

STL 容器的右值引用限定符

rvalue ref-qualifiers for STL containers

c++

stl

ref-qualifier

编辑

编辑2