Created on 2012-10-15.00:00:00 last changed 94 months ago
[Moved to DR at the November, 2014 meeting.]
Proposed resolution (February, 2014):
Change _N4527_.12.9 [class.inhctor] paragraph 1 as follows:
A using-declaration (9.9 [namespace.udecl]) that names a constructor implicitly declares a set of inheriting constructors. The candidate set of inherited constructors from the class X named in the using-declaration consists of actual constructors and notional constructors that result from the transformation of defaulted parameters and ellipsis parameter specifications as follows:
all non-template constructorsfor each non-template constructor of X, the constructor that results from omitting any ellipsis parameter specification, andfor each non-template constructor of X that has at least one parameter with a default argument, the set of constructors that results from omitting any ellipsis parameter specification and successively omitting parameters with a default argument from the end of the parameter-type-list, and
all constructor templatesfor each constructor template of X, the constructor template that results from omitting any ellipsis parameter specification, andfor each constructor template of X that has at least one parameter with a default argument, the set of constructor templates that results from omitting any ellipsis parameter specification and successively omitting parameters with a default argument from the end of the parameter-type-list.
Change _N4527_.12.9 [class.inhctor] paragraph 2 as follows:
The constructor characteristics of a constructor or constructor template are
the template parameter list (13.2 [temp.param]), if any,
the
parameter-type-listparameter-type-list (9.3.4.6 [dcl.fct]), andabsence or presence of explicit (11.4.8.2 [class.conv.ctor])
, and.
absence or presence of constexpr (9.2.6 [dcl.constexpr]).
Change _N4527_.12.9 [class.inhctor] paragraph 4 as follows:
A constructor so declared has the same access as the corresponding constructor in X. It is constexpr if the user-written constructor (see below) would satisfy the requirements of a constexpr constructor (9.2.6 [dcl.constexpr]). It is deleted if the corresponding constructor in X is deleted (9.5 [dcl.fct.def]9.5.3 [dcl.fct.def.delete]) or if a defaulted default constructor (11.4.5 [class.ctor]) would be deleted, except that the construction of the direct base class X is not considered in the determination. An inheriting constructor shall not be explicitly instantiated (13.9.3 [temp.explicit]) or explicitly specialized (13.9.4 [temp.expl.spec]).
Issue 1350 clarified that the exception-specification for an inheriting constructor is determined like defaulted functions, but we should also say something similar for deleted, and perhaps constexpr.
Also, the description of the semantics of inheriting constructors don't seem to allow for C-style variadic functions, so the text should be clearer that such constructors are only inherited without their ellipsis.
History | |||
---|---|---|---|
Date | User | Action | Args |
2017-02-06 00:00:00 | admin | set | status: drwp -> cd4 |
2015-05-25 00:00:00 | admin | set | status: dr -> drwp |
2015-04-13 00:00:00 | admin | set | messages: + msg5401 |
2014-11-24 00:00:00 | admin | set | status: ready -> dr |
2014-03-03 00:00:00 | admin | set | messages: + msg4840 |
2014-03-03 00:00:00 | admin | set | status: drafting -> ready |
2013-05-03 00:00:00 | admin | set | status: open -> drafting |
2012-10-15 00:00:00 | admin | create |