C2x: 6.9.2 External object definitions: why is "shall not be an incomplete type" placed in Semantics rather than in Constraints?

Question

Follow-up question for: What is the rationale for "semantics violation does not require diagnostics"?.

N2596 working draft — December 11, 2020 ISO/IEC 9899:202x (E), 6.9.2 External object definitions, Semantics, 3:

If the declaration of an identifier for an object is a tentative definition and has internal linkage, the declared type shall not be an incomplete type.

This looks like a constraint — why is it placed in the section "Semantics" (a violation of the requirement does not require a diagnostic) rather than in the section "Constraints"?

UPD. Similar question: Understanding IEEE 754: why convertFromInt and convertToIntegerXXX are categorized as arithmetic operations and not conversion operations?.

Answer 1

This looks like a constraint

I agree.

— why is it placed in the section "Semantics" (a violation of the requirement does not require a diagnostic) rather than in the section "Constraints"?

With regard to the parenthetical, I do not take the question of whether a diagnostic is required to be a key distinction between a language constraint and a semantic rule. A constraint is a

restriction, either syntactic or semantic, by which the exposition of language elements is to be interpreted

(C17, 3.8/1)

That's a mouthful, to be sure, but it comes down to constraints being rules for what code matching the C lexical grammar in fact conforms overall to the language specification, and what doesn't. As a consequence, adherence to language constraint can always be evaluated at translation time, and code failing to satisfy a language constraint effectively is not expressed in C. That is, constraints are rules applying to source code. This is the context for the requirement that implementations diagnose constraint violations.

Semantic rules, on the other hand, explain what C code means or what program behavior is associated, if any. These are rules for the runtime behavior of programs and C language implementations.

Which is all a long way back around to: I agree, despite being listed among the semantic rules, paragraph 6.9.2/3 is by nature a language constraint.

I doubt whether anyone will be able to respond with authority on why it is placed among the semantic rules, but it is perhaps relevant here that exactly the same wording appears as a semantic rule in every published version of the language specification, all the way back to C89, which positioned "incomplete types" a bit differently than C11 and later do.

It might be that the original ANSI C committee took a liberty here in order to excuse compilers from diagnosing this issue, perhaps because they saw an ambiguity in whether that restriction should apply to incomplete types that are completed later in the translation unit. I'm not sure about that myself, today. It's entirely possible that this represented a compromise position.