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


136. Default arguments and friend declarations

Section:9.3.4.7  [dcl.fct.default]    Status:CD1    Submitter:Daveed Vandevoorde    Date:9 July 1999

[Moved to DR at 10/01 meeting.]

9.3.4.7 [dcl.fct.default] paragraph 4says,

For non-template functions, default arguments can be added in laterdeclarations of a function in the same scope. Declarations indifferent scopes have completely distinct sets of default arguments.That is, declarations in inner scopes do not acquire default argumentsfrom declarations in outer scopes, and vice versa.
It is unclear how this wording applies to friend function declarations.For example,
    void f(int, int, int=0);             // #1    class C {        friend void f(int, int=0, int);  // #2    };    void f(int=0, int, int);             // #3
Does the declaration at #2 acquire the default argument from #1, anddoes the one at #3 acquire the default arguments from #2?

There are several related questions involved with this issue:

  1. Is the frienddeclaration in the scope of class C or in the surrounding namespacescope?

    Mike Miller:9.3.4.7 [dcl.fct.default] paragraph 4is speaking about the lexical location of thedeclaration...The friend declaration occurs in a different declarative regionfrom the declaration at #1, so I would read [this paragraph] as saying that itstarts out with a clean slate of default arguments.

    Bill Gibbons:Yes. It occurs in a different region, although it declares a namein the same region (i.e. a redeclaration). This is the same as withlocal externs and is intended to work the same way. We decided thatlocal extern declarations cannot add (beyond the enclosing block) newdefault arguments, and the same should apply to friend declarations.

    John Spicer:The question is whether [this paragraph]does (or should) mean declarations that appear in the same lexicalscope or declarations that declare names in the same scope. In my opinion,it really needs to be the latter. It seems somewhat paradoxical to saythat a friend declaration declares a function in namespace scope yet thedeclaration in the class still has its own attributes. To make that workI think you'd have to make friends more like block externs that really dointroduce a name into the scope in which the declaration is contained.

  2. Should default arguments be permitted in friend functiondeclarations, and what effect should they have?

    Bill Gibbons:In the absence of a declaration visible in class scope to whichthey could be attached, default arguments on friend declarationsdo not make sense.[They should be] ill-formed, to prevent surprises.

    John Spicer:It is important thatthe following case work correctly:

            class X {                friend void f(X x, int i = 1){}        };        int main()        {                X x;                f(x);        }

    In other words, a function first declared in a friend declaration must bepermitted to have default arguments and those default arguments must beusable when the function is found by argument dependent lookup. The reasonthat this is important is that it is common practice todefine functionsin friend declarations in templates, and that definition is the only placewhere the default arguments can be specified.

  3. What restrictions should be placed on default argument usage withfriend declarations?

    John Spicer:We want to avoid instantiation side effects. IMO, the way to do thiswould be to prohibit a friend declaration from providing default argumentsif a declaration of that function is already visible.Once a function has had a default specified in a frienddeclaration it should not be possible to add defaults in another declarationbe it a friend or normal declaration.

    Mike Miller:The position that seems most reasonable to me is toallow default arguments in friend declarations to be used inKoenig lookup, but to say that they arecompletely unrelated to default arguments in declarations inthe surrounding scope; and to forbid use of a default argumentin a call if more than one declaration in the overload set hassuch a default, as in the proposed resolution forissue 1.

(See also issues21,95,138,139,143,165, and166.)

Notes from 10/99 meeting:

Four possible outcomes were identified:

  1. If a friend declaration declares a default parameter, allow noother declarations of that function in the translation unit.
  2. Same as preceding, but only allow the friend declaration if it isalso a definition.
  3. Disallow default arguments in friend declarations.
  4. Treat the default arguments in each friend declaration as adistinct set, causing an error if the call would be ambiguous.

The core group eliminated the first and fourth options fromconsideration, but split fairly evenly between the remaining two.

A straw poll of the full committee yielded the following results(given as number favoring/could live with/"over my dead body"):

  1. 0/14/5
  2. 8/13/5
  3. 11/7/14
  4. 7/10/9

Additional discussion is recorded in the "Record of Discussion" forthe meeting, J16/99-0036 = WG21 N1212. See also paperJ16/00-0040 = WG21 N1263.

Proposed resolution (10/00):

In 9.3.4.7 [dcl.fct.default], add following paragraph 4:

If a friend declaration specifies a default argument expression,that declaration must be a definition and shall be the only declarationof the function or function template in the translation unit.



[8]ページ先頭

©2009-2026 Movatter.jp