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

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)>);
}

在这种情况下dectype（a）是int（可能），因为这个项目符号（工作草稿）：

如果e是命名结构化绑定[...]的无括号id表达式，dectype（e）是结构化绑定声明规范中给出的引用类型

这是@Curity在评论中为感兴趣的人提供的关于wandbox的片段。它表明实际上a不是引用，仅此而已。
到目前为止，对于最初的问题，OP问为什么它是int而不是int

不管怎样，我想知道委员会为什么决定这么做。一天结束时，a引用元组中的一个元素，我可以通过a修改该元素。换句话说，a的声明看起来像引用的声明，它的行为类似于引用，但它不是引用。

我可以接受，但我想知道这背后的原因是什么。为什么decltype（a）不能只是int




Answer 1

这个主题之前已经讨论过（查看structured bindings标签），第二个答案中甚至提到了您所讨论的行为。然而，p0144r2第3.5节阐述了基本原理：

语法应该扩展为允许const吗/

例如：

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);

Answer 2

我昨天写的：

decltype（x），其中x是结构化绑定，命名该结构化绑定的引用类型。在类似元组的情况下，这是由std:：tuple_元素返回的类型，它可能不是引用，即使在这种情况下，结构化绑定本身实际上始终是引用。这有效地模拟了绑定到结构的行为，该结构的非静态数据成员具有由tuple_元素返回的类型，绑定本身的引用性只是实现细节。