C2x：6.9.2 外部对象定义：为什么“不应是不完整类型”放置在语义中而不是约束中？

Question

\n

N2596 工作草案 \xe2\x80\x94 2020 年 12 月 11 日 ISO/IEC 9899:202x (E)，6.9.2 外部对象定义，语义，3：

\n

\n
如果对象标识符的声明是暂定定义并且具有内部链接，则声明的类型不应是不完整类型。
\n

\n

这看起来像一个约束 \xe2\x80\x94 为什么它被放置在“语义”部分（违反要求不需要诊断）而不是“约束”部分？

\n

\n

Answer 1

\n
这看起来像是一个约束
\n

\n

我同意。

\n

\n
\xe2\x80\x94 为什么它被放置在“语义”部分（违反要求不需要诊断）而不是“约束”部分？
\n

\n

关于括号，我不认为诊断是否需要成为语言约束和语义规则之间的关键区别。约束是一个

\n

\n
限制，无论是语法上的还是语义上的，通过它来解释语言元素的阐述
\n

\n

（C17，3.8/1）

\n

当然，这很拗口，但它归结为约束，即哪些与 C 词法语法匹配的代码实际上总体上符合语言规范，哪些不符合。因此，始终可以在翻译时评估对语言约束的遵守情况，并且无法有效满足语言约束的代码不会用 C 表示。也就是说，约束是应用于源代码的规则。这是实现诊断约束违规的要求的背景。

\n

另一方面，语义规则解释 C 代码的含义或相关的程序行为（如果有）。这些是程序和 C 语言实现的运行时行为的规则。

\n

这完全可以追溯到：我同意，尽管被列在语义规则中，第 6.9.2/3 段本质上是语言约束。

\n

我怀疑是否有人能够权威地回答为什么将其置于语义规则中，但这里可能相关的是，完全相同的措辞作为语义规则出现在语言规范的每个已发布版本中，一直追溯到到 C89，它对“不完整类型”的定位与 C11 及更高版本的做法略有不同。

\n

最初的 ANSI C 委员会可能在这里冒昧地原谅编译器诊断此问题，也许是因为他们认为该限制是否适用于稍后在翻译单元中完成的不完整类型存在歧义。今天我自己对此也不确定。这完全有可能代表一种妥协的立场。

\n