@opensdh: While [basic.pre] defines "declaration", it doesn't define "declarator" (non-grammar). Should the definition of locus be changed to refer to the grammar non-terminal instead:

The locus of a declaration ([basic.pre]) that has a declarator is immediately after the complete declarator ([dcl.decl]).

The use of "declaration" here refers to the definition in [basic.pre]/5. (At one point you wanted to call this a name-declaration, but the required edits were ugly.) The use of a non-grammar "declarator" is meant to follow the usage in [dcl.meaning.general]/1 and [dcl.ref]/1 and to refer to init-declarators, member-declarators, parameter-declarations, certain conditions, and exception-declarations, not all of which even contain a declarator. If anything, [dcl.meaning.general]/2 is in error in using the grammar term, although the condition case does have more or less the infirmity claimed here for a function-definition.

@opensdh we are expecting that [basic.scope.pdecl] p1 can be as a common rule to cover most normal cases that have a declarator. IMHO, init-declarators, member-declarators, parameter-declarations, certain conditions, and exception-declarations, if they are declarations and they introduce names, they all have declarator. Such as a parameter-declaration that introduces a name, its grammar is

• attribute-specifier-seq _optthis_opt decl-specifier-seq declarator
• attribute-specifier-seq_optthis_optdecl-specifier-seq declarator = initializer-clause

void fun(int a = sizeof(a));

The parameter-declaration, in this case, is int a = sizeof(a), the declarator introduces a name a, which is visible in its initializer-clause. BTW, GCC rejects this example while Clang accepts it.

@opensdh, I agree with "declaration" and [basic.pre] p5.

However, using "declarator" as a shorthand for init-declarator (etc.) gets the wrong result for unsigned int x = x;: The init-declarator is x = x; the complete "declarator" would thus be x = x, but we want to introduce "x" just before hitting the "=".

I think rephrasing this in terms of grammar-term declarator makes a lot of sense; all the places you mentioned do contain a declarator when introducing a name. (An abstract-declarator doesn't need a locus, because it doesn't introduce a name.)

It's true that we can ignore abstract-declarators here, but a declaration of a bit field has no declarator. (We would also need to change [basic.pre]/5.5 to say that it's the declarator in a condition that is the declaration rather than such a condition itself.)

I think we agree there is a definition problem (or rather, a lack of definition) for "declarator". We also agree that a bit-field needs special treatment. (Is the identifier in scope after the colon?)

What's wrong with saying that the entire condition with a declarator is a "declaration", yet the locus is immediately after the complete declarator? There is only one complete declarator per "declaration".

I also agree that the use of "declarator" in [dcl.meaning.general]/1 almost helps, but doesn't claim to be a formal definition of "declarator".

However, [dcl.ref]/1 is just wrong: For void& x, the declarator is & x, and the prohibition doesn't apply (the decl-specifier-seq is not part of the declarator). Maybe we should just say "Forming the type reference to cv void is ill-formed."

The only problem with the condition is that the locus is described for a "declaration" that is a "declarator", not that happens to contain one. We could perhaps achieve the same thing by changing [basic.scope.pdecl]/1 rather than [basic.pre]/5.5.

I think using "contain" may be clear here. Since we have defined the extent to which "contain" used in a declaration will apply, in [dcl.pre] p2.

void fun(int a){}

The locus of the function-definition is immediately after the declarator fun(int a) contained in the declaration, not the declarator a nested within it.

[dcl.pre] p2 is limited to clause 9, which does not influence [basic.scope.pdecl].

[dcl.pre] p2 is limited to clause 9, which does not influence [basic.scope.pdecl].

If I remember correctly, the right interpretation of many rules dispersed in other clauses relies on the application of [dcl.pre] p2.

We're trying to fix those other clauses in due course.

We're trying to fix those other clauses in due course.

That's great. I just think [dcl.pre] p2 should not be limited to only applying to clause 9 but should also uniformly apply to declarations when we refer to their components by using certain prepositions, which can be convenient to phrase something we expect. Such as the above example, when we draft [basic.scope.pdecl] p1(a declaration that has a declarator), we just intend to talk about the declarator on the top-level of that declaration, not the declarator that appears in the parameter-declaration. From an English language perspective, "has" should have covered the nested declarator, however, it is not what we expected when we draft that rule.

I'm painfully aware of the ambiguity with "has".

I think it's plain that we need some new terms for this direct sort of containment relationship. (In certain cases, we've already introduced terms like substatement.) In the upwards direction, we've had some success with "If the x is the x of a y,", but it might be worthwhile to define, say, the relationship between a y and the 0 or 1 x that it contains, ignoring any edge in the graph of non-terminals that would allow it to contain an arbitrary number of xs.

I'm painfully aware of the ambiguity with "has".

Not even only "has"(e.g. "in", specifically, see #5166), we seem to have much similar wording dispersed in these rules that may have ambiguities. I have the same thought with @opensdh's opinion: new terms for this direct sort of containment relationship are necessary. I would prefer to define the common terms and can conveniently use them to draft what we want to express than give the special specification when we draft each rule that would potentially use a wording with ambiguity meaning.

CWG2550 for the bad use of "declarator" in [dcl.ref] p1.

Yes, fixed.