You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
if T is a (possibly cv-qualified) class type ([class]), then
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 the semantic constraints for default-initialization are checked, and if T has a non-trivial default constructor, the object is default-initialized;
[...]
It seems that if T has no default constructor, then it can't meet the semantic constraints for default-initialization, and the "otherwise" branch correctly makes it ill-formed. (It doesn't matter whether zero-initialization is performed or not, since the initialization is ill-formed either way.)
CWG 1301 adds the "no default constructor" part. When CWG 1301 was adopted, the "otherwise" branch was not specified to check the semantic constraints for default-initialization (which was changed later by CWG 1507). Now that the "otherwise" branch does the right thing, I think it's not necessary to handle the "no default constructor" in the "if" branch.
Suggestion:
To value-initialize an object of type T means:
if T is a (possibly cv-qualified) class type ([class]), then
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 the semantic constraints for default-initialization are checked, and if T has a non-trivial default constructor, the object is default-initialized;
[...]
The text was updated successfully, but these errors were encountered:
I have a mild preference for keeping the status quo:
With the change, objects without a default constructor are zero-initialized before giving an error.
"semantic constraints for default init" is intended to perform template instantiations as needed; adding the "no default ctor" case on top of that rather vague phrase doesn't feel like an improvement.
[dcl.init.general]:
It seems that if
T
has no default constructor, then it can't meet the semantic constraints for default-initialization, and the "otherwise" branch correctly makes it ill-formed. (It doesn't matter whether zero-initialization is performed or not, since the initialization is ill-formed either way.)CWG 1301 adds the "no default constructor" part. When CWG 1301 was adopted, the "otherwise" branch was not specified to check the semantic constraints for default-initialization (which was changed later by CWG 1507). Now that the "otherwise" branch does the right thing, I think it's not necessary to handle the "no default constructor" in the "if" branch.
Suggestion:
The text was updated successfully, but these errors were encountered: