<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
  <head>
    <title>N2376 Inheriting Constructors (revision 2)</title>
    <base href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/" />
    <meta http-equiv="content-type" content="text/html; charset=utf-8" />
<style type="text/css">
  p {text-align:justify}
  li {text-align:justify}
  ins {background-color:#FFFF99}
  del {background-color:#FF9999}
</style>

  <body>
    Document Number: N2376=07-0236<br />
    2007-07-30<br />
    Alisdair Meredith &lt;alisdair.meredith@uk.renaultf1.com&gt;<br />
    Michael Wong &lt;michaelw@ca.ibm.com&gt;<br />
    Jens Maurer &lt;Jens.Maurer@gmx.net&gt;<br />
    
    <h1>Inheriting Constructors (revision 2)</h1>
    
    <p>
    This paper is a revision of <a href="2007/n2254.html">N2254</a>
    "Inheriting Constructors (revision 1)" by Alisdair Meredith, Michael Wong,
    Jens Maurer.
    </p>

    <h2>Problem Description</h2>
    
    <p>
    There is often a desire to initialize a derived class with exactly the
    same set of constructors as its base. This typically ends up with a series
    of tediously simply forwarding declarations and definitions. This work
    could be more easily handled by the compiler, is less error-prone when
    handled by the compiler, and the intent is clearer to read if the
    forwarding problem can be reduced to a single statement.
    </p>
    <p>
    There are also a couple of cases where the forwarding constructors cannot
    be declared by the user, such as for a dependant base class where a class
    template derives from one (or more) of its own template type parameters.
    </p>
    
    
    <h2>Outline of the Solution</h2>

    <p>
    Initial analysis was supplied by Francis Glassborow
    (<a href="2004/n1583.pdf">N1583</a>) and after further feedback from the
    evolution group, the direction was to word the simplest feature possible
    without making any effort to support extended use cases. The more
    complicated examples will probably be handled by a different language
    feature - a variadic constructor template.
    </p>
    <p>
    The basic idea is to implicitly declare a set of <em>forwarding
    constructors</em> with a syntax very similar to a using declaration. Like
    other implicitly declared constructors, they are only implicitly defined
    if they are <em>used</em>.
    </p>
    <p>
    Copy and default constructors are not forwarded, deferring to the existing
    rules for implicitly declaring copy/default constructors.
    </p>
    <p>
    As forwarding constructors are implicitly declared, they do not inhibit
    the implicit declaration of the default constructor.
    </p>
    <p>
    Forwarding constructors retain the throw spec, explicitness, constexpr
    qualifier and = delete flag of the base constructor.
    </p>
    <p>
    Forwarding constructors are defined in a similar manner to an implicitly
    defined default constructor, so additional bases and data members are
    subject to default initialization.  Arguments to the base class
    constructor are 'perfectly forwarded' using rvalue-references.
    </p>
    <p>
    User declared constructors inhibit forwarding for that particular
    signature, much as user declaration of a function would hide a specific
    signature when using declarations are used with regular functions.
    </p>
    <p>
    If multiple fwd-constructors-declarations declare
    the same signature, the program is ill-formed, even if those constructors
    are not used. This can be worked around with a user-declared constructor
    instead, which inhibits the problem declarations.
    </p>
    <p>
    It is often an error for multiple fwd-constructors-declarations to refer
    to the same base class. However, if a fwd-constructor-declaration does not
    actually lead to any implicit declarations, then there will be no problems
    if it is ued multiple times, although this is storing up fragile base
    class problems if constructors are added to that base in the future.
    </p>
    <p>
    A program is ill-formed if a fowarding constructor is <em>used</em> that
    forwards to a base class constructor that is declared private. Note that
    this is different to the using declarations with regular functions, that
    are ill-formed even if the private function is not used. It is consistent
    with the way a variadic constructor template would work though.
    </p>
    <p>
    Typically, forwarding constructor definitions for classes with virtual
    bases will be ill-formed, unless the virtual base supports default
    initialization, or the virtual base is a direct base, and named as the
    base forwarded-to. Likewise, all data members and other direct bases
    must support default initialization, or any attempt to use a forwarding
    constructor will be ill-formed. Note: ill-formed when used, not declared.
    </p>
   
    
    <h2>Summary of Changes</h2>

    Changes in the wording from the previous paper:
    <ul>
      <li>
        apply "using default T" syntax, which is not riding on the grammar
        for <em>using-declaration</em> any more.
      </li>
      <li>handle deleted constructors</li>
    </ul>

    Changes accumulated since CWG review in Oxford:
    <ul>
      <li>handle constexpr</li>
      <li>properly forward rvalues</li>
    </ul>

    <h2>Proposed Changes to the Working Paper</h2>

    <p>
      Change the grammar before 9.2p1 as indicated:
    </p>
    <blockquote>
<pre>
<em>member-declaration</em>:
     <em>decl-specifier-seq</em><sub>opt</sub> <em>member-declarator-list</em><sub>opt</sub> ;
     <em>function-definition</em> ;<sub>opt</sub>
     ::<sub>opt</sub> <em>nested-name-specifier</em> template<sub>opt</sub>
     <em>unqualified-id</em> ;
     <em>using-declaration</em>
     <em>static_assert-declaration</em>
     <em>template-declaration</em>
     <ins><em>fwd-constructors-declaration</em></ins>
</pre>
    </blockquote>

    <p>
      As fwd-constructors-declarations can declare an empty set of
      constructors, amend 9.2p1 as indicated.  Note we also allow for static
      assertions, which appear to be disallowed with the current wording.
    </p>

    <blockquote>
    <p>
      Except when used to declare friends (11.4)<del> or</del><ins>,</ins> to introduce the name of a member of a base class into a derived class (7.3.3,11.3), <ins>or as a <em>static_assert-declaration</em> (7 dcl.dcl),</ins> <em>member-declaration</em>s declare members of the class<del>, and each</del>. Each such member-declaration <ins>other than a <em>fwd-construcutor-declaration</em></ins> shall declare at least one member name of the class. A member shall
not be declared twice in the <em>member-specification</em>, except that a nested class or member class template can be declared and then later defined.
    </p>
    </blockquote>

    Create a new section 12.9 class.fwd [not shown in <inS>markup</ins> here]:
    <blockquote>
      12.9 Forwarding Constructors [class.fwd]
<pre>
<em>fwd-constructors-declaration</em>:
     using default ::<sub>opt</sub> <em>nested-name-specifier</em><sub>opt</sub> <em>class-name</em>
</pre>
    <p>
    A <em>fwd-constructors-declaration</em> declares a set of
    <em>forwarding constructors</em>. The class named shall be a direct
    base class of the class being defined.
    </p>
    <p>
    For each non-template constructor other than a default or copy
    constructor in the class named in the <em>fwd-constructors-declaration
    </em>, a constructor is implicitly declared with the same
    parameter-type-list (8.3.5 dcl.fct), <em>exception-specification</em>
    (15.4 except.spec), absence or presence of <code>explicit</code>
    (7.1.2 dcl.fct.spec), and absence or presence of <code>constexpr</code>
    (7.1.6 dcl.constexpr), unless there is a user-declared constructor with
    the same signature in the class where the
    <em>fwd-constructors-declaration</em> appears. Similarly, for each
    constructor member function template in the class named in the
    <em>fwd-constructors-declaration</em>, a constructor member function
    template is implicitly declared with the same template parameter list
    (14.1 temp.param), parameter-type-list (8.3.5 dcl.fct),
    <em>exception-specification</em> (15.4 except.spec), absence or
    presence of <code>explicit</code> (7.1.2 dcl.fct.spec), and absence or
    presence of <code>constexpr</code> (7.1.6 dcl.constexpr) unless there
    is an equivalent user-declared constructor member function template
    (14.5.5.1 temp.over.link) in the class where the
    <em>fwd-constructors-declaration</em> appears. [<em>Note:</em> Default
    and copy constructors may be implicitly declared as specified in 12.1
    class.ctor and 12.8 class.copy.]
    </p>
    <p>
    A constructor so declared has the accessibility as if it were declared
    with the <em>access-specifier</em> that applied to the corresponding
    constructor in the base class.  It is deleted if the corresponding base
    class constructor is deleted (8.4 dcl.fct.def).
    </p>
    <p>
    An implicitly-declared forwarding constructor for a class is
    implicitly defined when it is used (3.2 basic.def.odr) to create an
    object of its class type (1.8 intro.object). An implicitly-defined
    forwarding constructor performs the set of initializations of the
    class that would be performed by a user-written <code>inline</code>
    constructor for that class with a <em>mem-initializer-list</em> whose
    only <em>mem-initializer</em> has a <em>mem-initializer-id</em> that
    names the base class named in the
    <em>fwd-constructors-declaration</em> and an <em>expression-list</em>
    as specified below, and with an empty function body
    (12.6.2 class.base.init). If that user-written constructor would be
    ill-formed, the program is ill-formed. Each <em>expression</em> in the
    <em>expression-list</em> is of the form <code>static_cast&lt;
    <em>T</em>&amp;&amp;&gt;(<em>p</em>)</code> where
    <code><em>p</em></code> is the name of the corresponding constructor
    parameter and <code><em>T</em></code> is the declared type of
    <code><em>p</em></code>.
    </p>
    <p>
    [ Example:
    </p>
<pre>
<code>
struct B1 {
  B1( int ) {}
};

struct B2 {
  B2( double ) {}
};

struct D1 : B1 {
  using default B1; // implicitly declares D1( int )
  int x;
};

D1 d(6);        // ok; d1.x is not initialized
D1 e;           // error: base class B1 has no default constructor

struct D2 : B2 {
  using default B2; // ok, implicitly declares D2( double )
  B1 b;
};

D2 f(1.0);      // error: use of D2( double ) is ill-formed

template&lt; class T &gt;
struct D : T {
  using default T;   // declares all constructors from class T
  ~D() { clog &lt;&lt; "Destroying wrapper" &lt;&lt; endl; }
};
</code>
</pre>

    Class template <code>D</code> wraps any class and forwards all its
    constructors, while writing a message to the standard log whenever an
    object of class <code>D</code> is destroyed.
    <p>
    ]
    </p>
    <p>
    [<em>Note:</em> If two <em>fwd-constructors-declaration</em> declare
    forwarding constructors with the same signatures, the program is
    ill-formed (9.2 class.mem).
    </p>
    <p>
    [ Example:
    </p>
<pre>
<code>
struct B1 {
  B1( int );
};

struct B2 {
  B2( int );
};

struct D1 : B1, B2 {
  using default B1;
  using default B2;  // ill-formed implicitly declaring same ctor twice
};

struct D2 : B1, B2 {
  using default B1;
  using default B2;
  D2( int );  // user declaration prevents conflict
};
</code>
</pre>] ]
    <p>
    &nbsp;
    </p>
    </blockquote>


    While drafting the wording for this paper, it occurred to one of the
    authors that the standard currently defines "default constructor" in
    terms of whether a constructor can be called with no arguments. Thus, for
    a class <code>C</code>, <code>C(int x = 42)</code> is a default
    constructor. An implicitly declared default constructor could have that
    signature, which seems a bit surprising. Unrelated to the proposed
    semantics in this paper, we propose to change 12.1 class.ctor paragraph 5
    as follows
    <blockquote>
    A <em>default constructor</em> for a class X is a constructor of class X
    that can be called without an argument. If there is no user-declared
    constructor for class X, a <del>default</del> constructor <ins>with no
    arguments</ins> is implicitly declared. ...
    </blockquote>
    
    <h2>Acknowledgements</h2>
    Bjarne Stroustrup gave repeated encouragement for the authors to persevere
    and return with the simplest proposal possible. Steve Adamczyk proposed
    the <code>using default T;</code> syntax.
  </body>
</html>
