JTC1/SC22/WG21 N0756

                                Document Number:        X3J16/95-0156
                                                        WG21/N0756
                                Date:                   18 July 1995
                                Reply to:               John Wilkinson
                                                        jfw@sgi.com
 
        Default Arguments in Member Function Definitions
 
 
 
 
At the Monterey meeting, the Core I working group suggested that a restriction
be added to the Working Paper prohibiting default arguments from appearing in
out-of-class member function definitions.  The idea for the restriction arose
during the discussion of the One Definition Rule, the formulation of which
it somewhat simplifies.  The committee was favorable to the proposal, but
it was withdrawn from consideration as a formal motion under the (friendly)
threat of an invocation of the two-week rule.  Some people thought the
restriction was too sweeping to be imposed just to simplify the formulation
of the ODR.  The purpose of this paper is to defend the proposal.
 
I shall argue for eliminating the possibility of adding default arguments in
an out-of-class member function definition (hereafter called "the feature")
on the following grounds:
 
   o  the feature is useless
   o  it is noxious
   o  it complicates the language description
   o  it is unlikely to be used in much existing code
   o  it is trivial to eliminate its use wherever it appears
 
I shall address each of these in turn.
 
(1)   The feature does not add any functionality to the language.  Unlike
an ordinary function, which can have different sets of default arguments in
different scopes, a member function can add default arguments only in an
out-of-class definition, of which there can be only one.  The capability
to hide a default over some stretch of text does not seem to me to be
useful, though I gather there are those who disagree.  Note also that by
the last sentence of 8.3.6, paragraph 4, default arguments can not be added
to non-inline member function definitions, unless the class is declared in
only a single translation unit; and that for inline definitions, exactly the
same default arguments must be added in every translation unit, so the
feature is already hedged with severe restrictions.
 
(2)  The feature violates the natural and useful assumption that the class
declaration specifies the class interface.  With this feature you cannot
tell, for example, from a class declaration, whether or not the class has
a default constructor.  Default constructors can appear or disappear in the
middle of a program, and similar horrors can arise with copy constructors.
 
(3)  The restriction noted above (8.3.6, paragraph 4), is already more
complicated than a simple prohibition, and all of paragraph 6 is also
devoted to this feature.  Furthermore, the description of the ODR is
simplified by elimination of the feature.
 
(4)  This is of course just an opinion unsupported by hard evidence, but
the feature is of relatively recent (at an rate post-ARM) vintage, and is
probably not mentioned in most programmers' references.  Most people will
choose a familiar feature over an unfamiliar one, unless the unfamiliar
one solves some problem for them, which seems very unlikely in this case.
 
(5)  In any case where default arguments occur in an out-of-class definition,
they can simply be moved back to the in-class declaration, a two-line change.
Note that a corresponding restriction for ordinary functions could require
changing many function calls, not just two declarations.
 
Working paper changes:
 
Delete the last sentence of 8.3.6, paragraph 4
 
Replace 8.3.6, paragraph 6 by the single sentence
 
   "Default arguments may not appear in an out-of-line member function
    definition."