Closed t3nsor closed 2 months ago
CWG2859
"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.
"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.
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.
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.
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: