C23标准中同命名空间同名实体作用域重叠规则冗余性疑问

所有其他标识符的作用域由其声明位置（在声明符或类型说明符中）决定。若声明标识符的声明符或类型说明符出现在任何块或参数列表之外，该标识符具有file scope，其作用域在translation unit末尾终止。若出现在块内或函数定义的参数声明列表中，该标识符具有block scope，作用域在关联块末尾终止。若出现在函数原型（非函数定义）的参数声明列表中，该标识符具有function prototype scope，作用域在函数声明符末尾终止。若同一命名空间中的标识符指代两个不同实体，其作用域可能重叠。**若出现这种情况，其中一个实体的作用域（inner scope）将严格先于另一个实体的作用域（outer scope）结束。**在inner scope内，标识符指代inner scope中声明的实体；outer scope中声明的实体被hidden（不可见）。

你提出的关于加粗规则是否冗余的疑问，核心在于是否能通过语法和作用域终止规则直接推导该约束——答案是否定的，这条规则并非冗余，必要性体现在以下几点：

• 语法规则无法覆盖所有合法作用域重叠场景
  虽然DR345给出的函数参数与同名文件作用域标识符的场景，确实能通过“块被包含在翻译单元内”推导作用域结束顺序，但C标准需要覆盖所有可能的合法作用域重叠情况。早期C标准存在一些现在被约束的写法，显式规则能杜绝这类场景下的实现歧义。

• 解决DR345暴露的名称隐藏逻辑歧义
  DR345的本质问题是：当两个同名标识符作用域重叠时，若没有明确的“内作用域先结束”规则，编译器对名称隐藏的范围可能产生不同解读。比如假设存在某种（当前不合法的）写法，让外作用域的一部分被内作用域覆盖、内作用域结束后外作用域继续，没有这条规则的话，标准无法明确该场景下标识符的指代关系。

• 标准规则的明确性要求
  C标准的规则不仅要能被编译器实现者推导，还要让程序员清晰理解。这条加粗规则是显式定义作用域重叠时的层次关系，避免依赖“语法包含关系推导”这种间接逻辑。即使部分场景能推导，显式规则也能消除歧义，提升标准可读性，减少不同编译器的实现差异。

以DR345的示例来说：参数f的block scope在函数体块末尾终止，文件作用域的f在翻译单元末尾终止——虽然语法上块包含于翻译单元，但标准需要明确这种场景属于“内作用域先结束”的情况，进而清晰界定函数体内部f指代参数、外部指代文件作用域实体。如果没有这条显式规则，理论上可能存在编译器对“作用域重叠优先级”的不同理解（尽管实际不会发生，但标准必须彻底杜绝这种可能性）。

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