Movatterモバイル変換


[0]ホーム

URL:


This is an unofficial snapshot of the ISO/IEC JTC1 SC22 WG21 Core Issues List revision 119a. See http://www.open-std.org/jtc1/sc22/wg21/ for the official list.

2025-12-20


140. Agreement of parameter declarations

Section:9.3.4.6  [dcl.fct]    Status:CD1    Submitter:Steve Clamage    Date:15 Jul 1999

[Moved to DR at 10/01 meeting.]

9.3.4.6 [dcl.fct] paragraph 3says,

All declarations for a function with a given parameter list shallagree exactly both in the type of the value returned and in thenumber and type of parameters.
It is not clear what this requirement means with respect to a pairof declarations like the following:
    int f(const int);    int f(int x) { ... }
Do they violate this requirement? Isx const in the body ofthe function declaration?

Tom Plum:I think the FDIS quotation means that the pair of decls are valid.But it doesn't clearly answer whetherx isconst inside the function definition.As to intent, Iknow the intent was that if the functiondefinition wants to specify thatx isconst,theconst must appear specifically in the definingdecl, not just on some decl elsewhere.But I can't prove that intent from the drafted words.

Mike Miller:I think the intent was something along thefollowing lines:

Two function declarations denote the same entity ifthe names are the same and the function signaturesare the same. (Two function declarations with Clanguage linkage denote the same entity if the namesare the same.) All declarations of a given functionshall agree exactly both in the type of the valuereturned and in the number and type of parameters;the presence or absence of the ellipsis is consideredpart of the signature.
(See 6.7 [basic.link] paragraph 9.That paragraph talks about names in differentscopes and says that function references are the same if the"types are identical for purposes of overloading," i.e., thesignatures are the same. See also9.12 [dcl.link] paragraph 6regarding C languagelinkage, where only the name is required to be the same fordeclarations in different namespaces to denote the samefunction.)

According to this paragraph, the type of a parameter isdetermined by considering itsdecl-specifier-seq anddeclaratorand then applying the array-to-pointer and function-to-pointeradjustments. Thecv-qualifier and storage class adjustmentsare performed for the function type but not for the parametertypes.

If my interpretation of the intent of the second sentence ofthe paragraph is correct, the two declarations in the exampleviolate that restriction — the parameter types are not thesame, even though the function types are. Since there's nodispensation mentioned for "no diagnostic required," animplementation presumably must issue a diagnostic in thiscase. (I think "no diagnostic required" should be stated ifthe declarations occur in different translation units —unless there's a blanket statement to that effect that I haveforgotten?)

(I'd also note in passing that, if my interpretation iscorrect,

    void f(int);    void f(register int) { }
is also an invalid pair of declarations.)

Proposed resolution (10/00):

  1. In Clause 3 [intro.defs] “signature,” change"the types of its parameters"to"its parameter-type-list (9.3.4.6 [dcl.fct])".

  2. In the third bullet of 6.7 [basic.link] paragraph 9change"the function types are identical for the purposes of overloading"to"the parameter-type-lists of the functions (9.3.4.6 [dcl.fct]) are identical."

  3. In the sub-bullets of the third bullet of7.6.1.5 [expr.ref] paragraph 4, change all four occurrencesof"function of (parameter type list)"to"function of parameter-type-list."

  4. In 9.3.4.6 [dcl.fct] paragraph 3, change

    All declarations for a function with a given parameter list shall agreeexactly both in the type of the value returned and in the number andtype of parameters; the presence or absence of the ellipsis isconsidered part of the function type.
    to
    All declarations for a function shallagree exactly in both the return type and theparameter-type-list.

  5. In 9.3.4.6 [dcl.fct] paragraph 3, change

    The resulting list of transformed parameter types is the function'sparameter type list.
    to
    The resulting list of transformed parameter types and the presence orabsence of the ellipsis is the function'sparameter-type-list.

  6. In 9.3.4.6 [dcl.fct] paragraph 4, change"the parameter type list"to"the parameter-type-list."

  7. In the second bullet of _N4868_.12.2 [over.load] paragraph 2,change all occurrences of "parameter types" to"parameter-type-list."

  8. In 12.2 [over.match] paragraph 1, change "the types ofthe parameters" to "the parameter-type-list."

  9. In the last sub-bullet of the third bullet of12.2.2.3 [over.match.oper] paragraph 3, change "parameter typelist" to "parameter-type-list."

Note, 7 Sep 2001:

Editorial changes while putting inissue 147brought up the fact that injected-class-name is not a syntax term andtherefore perhaps shouldn't be written with hyphens. The same can be said ofparameter-type-list.




[8]ページ先頭

©2009-2026 Movatter.jp