CWG2537 [dcl.fct] Overbroad grammar for parameter-declaration

[jensmaurer]

Full name of submitter (unless configured in github; will be published with the issue): Davis Herring

Reference (section label): dcl.fct 9.3.4.6

Link to reflector thread (if any): cplusplus/draft#4521

Issue description:

It should have a defining-type-specifier-seq instead of a decl-specifier-seq, since no other decl-specifier (a storage-class-specifier, a function-specifier, friend, typedef, constexpr, consteval, constinit, or inline) can be used there (unless we expect to get constexpr function parameters any day now!).

Suggested resolution:

[jensmaurer]

CWG2537

@opensdh, please have a look.

[opensdh]

[dcl.stc]/4, /5, [dcl.typedef]/1, and [dcl.inline]/4 can be simplified by removing references to function parameters.

[jensmaurer]

Fixed. I also found one more.

[opensdh]

Don't keep me in such suspense—what's the one more?

[jensmaurer]

@opensdh, just follow the link to CWG2537

[opensdh]

I did, but I see edits to only the four places I found.

[jensmaurer]

Ah, sorry, I had overlooked the /5 in your list. So, nothing extra. Sorry for the noise.

[opensdh]

In review yesterday we realized that the even narrower type-specifier-seq would be sufficient, which could replace part of [dcl.fct]/17.

Several places do use decl-specifier-seq to refer to the appropriate part of any declaration, which would need updating here:

• [basic.type.qualifier]/1
• [dcl.pre]/3–4, which unfortunately describe just simple-declarations in a fashion that really means to pertain to all declarator-based declarations
• [dcl.pre]/7, which has to choose between function/object declarations after parameter type adjustments
• [dcl.spec.general]/3
• [dcl.type.cv]/1, which already assumes that an init-declarator-list or member-declarator-list is available
• [dcl.spec.auto.general]/2, which could just be changed to type-specifier-seq
• [dcl.spec.auto.general]/5, which could use just type-specifier-seq for more cases
• [dcl.meaning.general]/4–6
• [temp.res.general]/4.3, whose parameter-relevant portions could be moved into /4.2

The sensible thing to do would presumably be to introduce a term (e.g., "the specifiers of a declaration are…") and use that everywhere. This is a larger change, of course, and might not be worth doing, although there the indicated places in the above list need work anyway.