关于C++26扩展语句中在非模板场景下使用structured binding packs的合法性问询

嘿，这是个相当犀利的问题——精准触碰到了C++26新特性（扩展语句）和结构化绑定包交互的规则边缘，我来一步步拆解给你捋清楚：

首先，咱们先锚定C++26草案里关于扩展语句（template for）的核心规则：

1. 扩展语句的for-range-declaration和复合语句（循环体）整体被视为模板定义
2. 补充规则明确：在扩展语句的范围声明或循环体内定义/创建的实体，都属于模板化实体（templated entity）

而结构化绑定包（就是你写的auto [...parts] = p;里的parts）有个硬要求：它只能在模板化上下文中声明——因为包本质上依赖编译时的展开上下文，而模板化实体刚好满足这个前提。

回到你的代码：

auto sum(Point p) -> int {
  template for (auto _ : {0}) {
    auto [...parts] = p;
    return (... + parts);
  }
}

从当前C++26草案的规则来看，这段代码是合法的，理由如下：

• 你用template for构造了一个扩展语句，哪怕循环范围{0}只会让它执行一次，它的循环体依然属于“模板定义区域”
• 循环体内的parts是在扩展语句的复合语句里定义的，按照补充规则，它属于模板化实体，完全满足结构化绑定包的声明要求
• Point是可解构的聚合类型，auto [...parts] = p;会正确把p.x/p.y/p.z绑定到parts包，后续的折叠表达式(... + parts)也能正常展开计算总和

至于你提到的P3525显式模板区域写法，虽然它是专门用来创建模板上下文的语法，但你的template for写法并没有“hacky”到违反规则——只是利用了扩展语句的模板区域特性来间接实现需求，从标准 wording 来说完全站得住脚。

那你有没有遗漏什么？其实没什么关键漏洞，不过可以提两个小细节：

1. 扩展语句的原始设计初衷是遍历可解构类型的成员（比如你最开始写的template for (int c : p)），你用{0}当范围属于“借壳”使用它的模板区域特性，虽然合法，但可能不是特性设计的原始场景
2. 要确保你的编译器已经实现了C++26扩展语句的完整规则（包括那个关于模板化实体的补充 wording）——毕竟这是草案阶段的特性，不同编译器的支持程度可能有差异

总的来说，你的写法在当前C++26草案的规则下是完全有效的，不用怀疑~

内容来源于stack exchange