C++结构化绑定中cv限定符传播规则相关技术咨询

场景1中x的const限定来源 #

这里x的const属性不是auto推导直接作用于成员产生的，是普通auto引用推导规则和结构化绑定专属语义共同作用的结果：

• 代码中f本身是const Foo类型的const对象。
• 对auto& [x, y] = f;来说，auto的推导完全遵循普通引用的推导逻辑：因为要绑定到const左值f，auto会被推导为const Foo，结构化绑定背后隐藏的底层引用类型就是const Foo&，这一步和普通auto&变量的推导没有任何区别。
• 按照dcl.struct.bind条款的明确要求，结构化绑定声明的x、y是被绑定对象成员的直接别名，类型必须携带被绑定对象的cv限定符，因此x的类型为const int，这是结构化绑定对别名的属性要求，不是auto推导直接修改了成员的类型。

cv传播的设计原因，以及与普通auto引用规则的一致性 #

cv传播的设计初衷 #

规则设计的核心出发点是守住const正确性的基本类型安全底线：
结构化绑定的语义是把对象的成员拆成当前作用域下可直接访问的别名，这些别名的访问权限必须和你声明的绑定类型（值/引用、const/非const）完全匹配。如果不强制传播cv限定，就会出现明显的类型漏洞：比如你写const auto& [x,y] = f本意是获得f的只读访问权，要是绑定出来的x、y不带const，就可以直接通过别名修改const对象的成员，彻底破坏const限定的只读约束。

所谓“规则不一致”是decltype规则造成的错觉 #

你观察到的decltype(x) == const int、decltype(rf.x) == int的差异，和const传播规则无关，完全是decltype对不同表达式的处理规则不同导致的，两种写法的实际const约束是完全一致的：

• 结构化绑定的x是独立的标识符，对应实体的类型就是const int。按照decltype的规则，decltype作用于标识符时，直接返回该标识符对应实体的类型，因此结果为const int。
• rf.x是类成员访问表达式，不是独立标识符。decltype对这类表达式的处理规则是直接返回成员在类定义中的声明类型，不会把访问路径上对象的cv限定符带入结果。但这绝不代表rf.x是可修改的：

const Foo f{1, 1.0};
const auto& rf = f;
// rf.x = 2; // 编译直接报错：不能给const对象的成员赋值，const约束实际生效
decltype(rf.x) a = 3; // 合法：a的类型是int，仅反映x在Foo中的声明类型，和访问权限无关

也就是说，不管是结构化绑定的x，还是普通const引用的rf.x，你都不能通过它们修改原const对象的成员，只读约束完全一致，根本不存在规则设计上的冲突。

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