结构化绑定：当某些东西看起来像引用并且行为类似于引用，但它不是引用时

Question

昨天我在 SO 上看到 an interesting question 关于结构化绑定。
我们可以总结如下。考虑下面的示例代码：

#include <tuple>
#include <type_traits>

int main() {
    auto tup = std::make_tuple(1, 2);
    auto & [ a, b ] = tup;
    // the following line won't compile for a isn't a reference
    // static_assert(std::is_reference_v<decltype(a)>);
}

在这种情况下，decltype(a) 是 int（可能）因为 this bullet（工作草案）：

如果 e 是一个无括号的 id 表达式，命名结构化绑定 [...]，则 decltype(e) 是结构化绑定声明规范中给出的引用类型

Here 是@Curious 在 cmets 中为感兴趣的人提供的魔杖盒上的 sn-p。它表明实际上a 不是参考，仅此而已。
到目前为止，原始问题的效果很好，OP 询问为什么它是 int 而不是 int & 并且标准说看起来是一个可以接受的答案。

无论如何，我想知道委员会为什么会这样决定。归根结底，a 指的是元组中的一个元素，我可以通过a 修改该元素。换句话说，a 的声明看起来像一个引用，它的行为类似于引用，但它不是引用。

我可以忍受这个，但我想知道这背后的原因是什么。为什么decltype(a) 不能简单地是int &？有没有一个世俗的人可以理解的有意义的理由？

Answer 1

I wrote this yesterday:

decltype(x)，其中x 是结构化绑定，将引用的名称命名为 该结构化绑定的类型。在类似元组的情况下，这是 std::tuple_element 返回的类型，可能不是引用 即使结构化绑定本身实际上总是 在这种情况下参考。这有效地模拟了 绑定到其非静态数据成员具有类型的结构 由tuple_element 返回，带有绑定的引用 本身只是一个实现细节。

Answer 2

这个主题之前已经介绍过（查看结构化绑定标签），您所说的行为甚至在第二个答案中得到了解决。但是，p0144r2 第 3.5 节详细说明了基本原理：

是否应该扩展语法以允许 const/&-qualifying 个人 名字的类型？

例如：

auto [&x, const y, const& z] = f(); // NOT proposed

我们认为答案应该是否定的。这是一个简单的功能来存储 值并将名称绑定到其组件，而不是声明多个 变量。允许这样的资格将是功能蠕变， 将功能扩展为不同的东西，即一种方法 声明多个变量。

如果我们确实想声明多个变量，我们已经有办法 拼写：

 auto val    = f();
 T& x        = get<0>(val);
 T2 const y  = get<1>(val);
 T3 const& z = get<2>(val);