结构化绑定:当某些内容看起来像引用并且行为类似于引用时,但它不是引用

sky*_*ack 20 c++ language-lawyer c++17 structured-bindings

昨天我在SO上看到了一个关于结构化绑定的有趣问题.
我们可以总结如下.请考虑以下示例代码:

#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)>);
}
Run Code Online (Sandbox Code Playgroud)

在这种情况下decltype(a)int(可能),因为这种子弹(工作草案):

if e是一个未加括号的id-expression,用于命名结构化绑定[...],decltype(e)是结构化绑定声明规范中给出的引用类型

是@Curious在评论中为感兴趣的人提供的wandbox片段.它表明实际上a不是参考,仅此而已.
到目前为止好于原来的问题,OP问为什么它int,而不是int &标准说,看上去像一个可以接受的答案.

无论如何,我想知道委员会为何如此决定.在一天结束时,a引用元组中的元素,我可以通过修改该元素a.换句话说,声明a看起来像一个引用,它的行为类似于引用,但它不是引用.

我可以忍受这个,但我想知道背后的原因是什么.为什么decltype(a)不能简单int &?亵渎者可以理解是否有一个有意义的理由?

T.C*_*.C. 10

我昨天写了这篇文章:

decltype(x),x结构化绑定在哪里,命名该结构化绑定的引用类型.在类似元组的情况下,这是返回的类型std::tuple_element,即使结构化绑定本身在这种情况下实际上始终是引用,也可能不是引用.这有效地模拟了绑定到非静态数据成员具有返回类型的结构的行为,tuple_element绑定本身的引用仅仅是实现细节.

  • 所以,用简单的话来说,它就像`some_struct.member`? (3认同)