CWG2859 [dcl.init.general] Value-initialization and multiple default constructors

[t3nsor]

Full name of submitter: Brian Bi

Reference (section label): [dcl.init.general]

Issue description: As pointed out on cppreference, the standard appears to say that if any default constructor is user-provided, then value-initialization does not first zero-initialize; but implementations appear to zero-initialize as long as the selected default constructor is not user-provided. I think the latter behavior is probably the intent of the standard.

Suggested resolution: This resolution is relative to the tentatively ready resolution of CWG2820.

Edit [dcl.init.general]/9.1 as follows:

If T is a (possibly cv-qualified) class type ([class]), then let C be the constructor selected to default-initialize an object of type T. If C is not user-provided, the object is first zero-initialized. Regardless of whether such zero-initialization was performed, the object is then default-initialized.

• if T has either no default constructor ([class.default.ctor]) or a default constructor that is user-provided or deleted, then the object is default-initialized;
• otherwise, the object is zero-initialized and then default-initialized.

[jensmaurer]

CWG2859

[cpplearner]

"Vacuous initialization" is defined in terms of default-initialization. If default-init is unconditionally performed as part of value-init, then it's implied that value-init could make a object have vacuous initialization.

The definition of "vacuous initialization" should probably be adjusted to exclude value-initialization.

[jensmaurer]

"Vacuous initialization" wants to say "no code runs", so we need to adjust this wording to say that the actual default constructor used in the initialization is trivial.

Other than that, "user-provided" implies "non-trivial", so I think we don't have any other problem here.

[t3nsor]

I think the issue that cpplearner pointed out is partially an issue with the CWG2820 resolution. Namely, value-initialization that uses a trivial default constructor should not be vacuous initialization (because it zero-initializes) but the resolution to CWG2820 would make it so. We may want to fix it there first and return it to "review" status, or perhaps combine these two issues into one.

[frederick-vs-ja]

After CWG2256, the term vacuous initialization is only essentially used in [stmt.dcl] (it doesn't need to be mentioned in [basic.life]). It seems that we can dissolve the term into [stmt.dcl] p2.