为何std::array<T,N>::operator[]不对右值对象返回右值引用？

一、std::array<int,1>{1}[0] = 3;的实际意义 #

这段代码语法合法但几乎无实际业务价值：它修改的是临时std::array对象的第一个元素，但临时对象在语句结束后就会被销毁，修改结果无法保留。

唯一能想到的特殊场景是利用赋值表达式的返回值，比如你给出的例子：

auto a = (std::array<int, 1>{1}[0] = 3);
assert(a == 3);

这里赋值表达式返回被修改后的元素左值引用，最终会被拷贝到a中，但这种写法非常少见，仅属于语法层面的特例。

二、std::get报错的原因 #

std::get<0>(std::array<int, 1>{1}) = 3;编译报错的核心是值类别不匹配：

• std::array<int,1>{1}是右值临时对象，C++11及以后标准中，std::get针对右值容器的重载会返回右值引用（T&&）。
• 内置类型的赋值运算符要求左值作为左操作数，而右值引用作为表达式时属于右值，无法被赋值，因此clang提示“表达式不可赋值”。

简言之：std::get会根据容器的左/右值属性返回对应值类别的引用，而operator[]不管容器是左值还是右值，始终返回左值引用。

三、当初标准化时的设计益处 #

1. 兼容性优先：C11引入右值引用前，所有容器的operator[]都返回左值引用。为兼容C98及更早的旧代码，标准委员会未修改这一行为——若改成右值容器返回右值引用，大量依赖operator[]返回左值的旧代码会直接编译失败。
2. 行为一致性：operator[]作为容器的传统访问接口，用户预期它能返回可修改的元素引用，不管容器本身是左值还是右值。统一的返回类型降低了用户学习成本，避免额外规则带来的复杂度。
3. 避免无意义限制：虽然修改临时容器元素大多是无意操作，但语法上禁止它并无必要——编译器可通过警告（如clang的-Wunused-value）提示用户可能的错误，而非直接禁止合法语法。

四、为何不修改标准让两者行为一致 #

1. 兼容性成本过高：现有C++代码库中大量依赖operator[]返回左值引用的行为，修改这一规则会导致大规模编译错误，这是标准委员会无法接受的。
2. 接口定位不同：std::get是针对元组类类型（含std::array）的类型安全访问接口，设计上更注重值类别匹配与类型严格性；而operator[]是容器的通用访问接口，优先考虑兼容性与直观性，两者设计目标本就不同。
3. 实际危害可控：修改临时容器元素的代码通常是笔误，编译器的警告已足够提醒用户，无需通过修改标准强制禁止。

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