--- title: "Fix inappropriate font choices for \"declaration\"" document: P3924R1 date: 2026-03-23 audience: CWG reply-to: - "Jan Schultke < " paper-type: proposal --- ### Changes since R0 - In § [dcl], added the after "or" in first two changes ## Introduction The C++ standard has two similar terms: - the regular-font "declaration" defined in [[basic.pre]](https://eel.is/c++draft/basic.pre) - the grammatical declaration defined in [[dcl]](https://eel.is/c++draft/dcl) There exist declarations that are not declarations, such as the elaborated-type-specifier `struct S`. There are instances where these have been used incorrectly. NB comment US 11-400 requests: > Perform a thorough review of each usage of the term "declaration" to confirm that it is rendered in the correct style. Such a review has been performed. The vast majority of occurrences are "declaration", not declaration. Since "declaration" is somewhat of a superset, the term can almost always be used without grammatical font. Using grammatical font is more likely to result in a mistake, so it should be done with great caution and confidence. In some cases, the surrounding wording is adjusted to fit the existing use of declaration. ## Wording Some mistakes in [[N5014]](https://wg21%2elink/n5014) have already been fixed, such as the misuse in [[basic.pre]](https://eel.is/c++draft/basic.pre) pointed out by US 12-026. ### [basic] Change [[basic.def] paragraph 2](https://eel.is/c++draft/basic.def#2) as follows: Each entity declared by a declaration is also defined by that declaration unless: - […] - it is an explicit specialization explicit-specialization ([[temp.expl.spec]](https://eel.is/c++draft/temp.expl.spec)) whose declaration is not a definition. Change [[basic.scope.scope] note 1](https://eel.is/c++draft/basic.scope.scope#note-1) as follows: [*Note*: Special cases include that: - […] - The declaration in declaration of a template-declaration inhabits the same scope as the template-declaration. - […] — *end note*] Do not change [[basic.link] paragraph 1](https://eel.is/c++draft/basic.link#1): > A program consists of one or more translation units ([[lex.separate]](https://eel.is/c++draft/lex.separate)) linked together. A translation unit consists of a sequence of declarations. > > **translation-unit:** > : […] The "introductory" wording at the start of subclauses that introduce various syntactical constructs could use grammatical font in many cases. However, this is a general issue, not specific to "declaration", and should be addressed holistically. ### [stmt] Do not change [[stmt.pre] paragraph 7](https://eel.is/c++draft/stmt.pre#7): > If a condition can be syntactically resolved as either an expression or a declaration, it is interpreted as the latter. This paragraph is updated separately, in [[CWG3132]](https://cplusplus%2egithub%2eio/CWG/issues/3132%2ehtml). Change [[stmt.block] paragraph 2](https://eel.is/c++draft/stmt.block#2) as follows: [*Note*: A compound statement defines a block scope ([[block.scope]](https://eel.is/c++draft/block.scope)). A declaration is a statement ([[stmt.dcl]](https://eel.is/c++draft/stmt.dcl)). — *end note*] Not every declaration is a statement, only a declaration-statement is. The second sentence is also unnecessary in general because the surrounding wording and the grammar are already clear. Change [[stmt.expand] paragraph 5, bullet 3](https://eel.is/c++draft/stmt.expand#5.3) as follows: Otherwise, S is a destructuring expansion statement and S is equivalent to: { init-statement constexpr opt auto&& [ u 0 , u 1 , …, u N − 1 ] = expansion-initializer ; S 0 ⋮ S N − 1 } where N is the structured binding size of the type of the expansion-initializer and Si is { for-range-declaration = u i ; compound-statement } The keyword `constexpr` is present in the declaration structured-binding-declaration of u0 , u1 , … , uN−1 if and only if `constexpr` is one of the decl-specifiers of the decl-specifier-seq of the for-range-declaration. ### [dcl] Change [[dcl.stc] paragraph 1](https://eel.is/c++draft/dcl.stc#1) as follows: […] If a storage-class-specifier appears in a decl-specifier-seq, there can be no `typedef` specifier in the same decl-specifier-seq and the init-declarator-list of the simple-declaration or the member-declarator-list of the declaration member-declaration shall not be empty (except for an anonymous union declared in a namespace scope ([[class.union.anon]](https://eel.is/c++draft/class.union.anon))). […] Change [[dcl.type.cv] paragraph 1](https://eel.is/c++draft/dcl.type.cv#1) as follows: […] If a cv-qualifier appears in a decl-specifier-seq, the init-declarator-list of the simple-declaration or the member-declarator-list of the declaration member-declaration shall not be empty. […] Do not change [[dcl.type.elab] paragraph 2](https://eel.is/c++draft/dcl.type.elab#2) as follows: > If an elaborated-type-specifier is the sole constituent of a declaration, the declaration is ill-formed unless it is an explicit specialization ([[temp.expl.spec]](https://eel.is/c++draft/temp.expl.spec)), a partial specialization ([[temp.spec.partial]](https://eel.is/c++draft/temp.spec.partial)), an explicit instantiation ([[temp.explicit]](https://eel.is/c++draft/temp.explicit)), or it has one of the following forms: > > […] If the wording was restricted to declarations, this rule may not apply because grammatically, a declaration cannot solely consist of a elaborated-type-specifier. Change [[dcl.decl.general] paragraph 3](https://eel.is/c++draft/dcl.decl.general#3) as follows: Each init-declarator of a simple-declaration or member-declarator of a member-declaration in a declaration is analyzed separately as if it were in a declaration simple-declaration or member-declaration by itself. Do not change [[dcl.ambig.res] paragraph 1](https://eel.is/c++draft/dcl.ambig.res#1): > […] However, a construct that can syntactically be a declaration whose outermost declarator would match the grammar of a declarator with a trailing-return-type is a declaration only if it starts with `auto`. The above also applies to things like function parameters, which are not declarations, but may syntactically match a declaration. Change [[dcl.meaning.general] paragraph 4](https://eel.is/c++draft/dcl.meaning.general#4) as follows: A `static`, `thread_local`, `extern`, `mutable`, `friend`, `inline`, `virtual`, `constexpr`, `consteval`, `constinit`, or `typedef` specifier or an explicit-specifier applies directly to each declarator-id in a declaration simple-declaration or member-declaration; the type specified for each declarator-id depends on both the decl-specifier-seq and its declarator. ### [class.dtor] Do not change [[class.dtor] paragraph 1](https://eel.is/c++draft/class.dtor#1): > A declaration whose declarator-id has an unqualified-id that begins with a `~` declares a prospective destructor; its declarator shall be a function declarator ([[dcl.fct]](https://eel.is/c++draft/dcl.fct)) of the form […] A declarator-id does not directly belong to a declaration. This wording seems to make use of the fact that separate declarators in a single declaration are separate declarations. Do not change [[class.conv.fct] paragraph 1](https://eel.is/c++draft/class.conv.fct#1): > A declaration whose declarator-id has an unqualified-id that is a conversion-function-id declares a conversion function; its declarator shall be a function declarator ([[dcl.fct]](https://eel.is/c++draft/dcl.fct)) of the form […] ### [over.literal] Do not change [[over.literal] paragraph 2](https://eel.is/c++draft/over.literal#2): > A declaration whose declarator-id is a literal-operator-id shall declare a function or function template […] ## References [N5014] Thomas Köppe. Working Draft, Programming Languages — C++ 2025-08-05 https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/n5014.pdf [CWG3132] CWG. Unclear disambiguation rule for condition 2025-11-21 https://cplusplus.github.io/CWG/issues/3132.html