Title
Value initialization with trivial inaccessible default constructor
Status
cd3
Section
9.4 [dcl.init]
Submitter
Johannes Schaub

Created on 2012-06-01.00:00:00 last changed 90 months ago

Messages

Date: 2013-04-15.00:00:00

[Moved to DR at the April, 2013 meeting.]

Date: 2013-02-15.00:00:00

Proposed resolution (February, 2013):

  1. Change 9.4 [dcl.init] paragraph 7 as follows:

  2. To default-initialize an object of type T means:

    • if T is a (possibly cv-qualified) class type (Clause Clause 11 [class]), the default constructor (11.4.5 [class.ctor]) for T is called (and the initialization is ill-formed if T has no accessible default constructor default constructor or overload resolution (12.2 [over.match]) results in an ambiguity or in a function that is deleted or inaccessible from the context of the initialization);

    • ...

  3. Change 9.4 [dcl.init] paragraph 8 as follows:

  4. To value-initialize an object of type T means:

    • ...

    • if T is a (possibly cv-qualified) non-union class type without a user-provided or deleted default constructor, then the object is zero-initialized and the semantic constraints for default-initialization are checked, and if T has a non-trivial default constructor, the object is default-initialized;

    • ...

Date: 2012-06-01.00:00:00

According to 9.4 [dcl.init] paragraph 7, a trivial default constructor is not used in value initialization, so the following example would appear to be well-formed:

  struct A { private: A() = default; };
  int main() { A(); }
History
Date User Action Args
2014-03-03 00:00:00adminsetstatus: drwp -> cd3
2013-10-14 00:00:00adminsetstatus: dr -> drwp
2013-05-03 00:00:00adminsetmessages: + msg4408
2013-05-03 00:00:00adminsetstatus: tentatively ready -> dr
2013-03-18 00:00:00adminsetmessages: + msg4247
2013-03-18 00:00:00adminsetstatus: drafting -> tentatively ready
2012-11-03 00:00:00adminsetstatus: open -> drafting
2012-06-01 00:00:00admincreate