Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[dcl.init.general] Could the definition of value-initialization be simplified? #5084

Open
cpplearner opened this issue Nov 2, 2021 · 2 comments

Comments

@cpplearner
Copy link
Contributor

[dcl.init.general]:

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;
  • [...]

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;
  • [...]
@jensmaurer
Copy link
Member

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.

@jensmaurer
Copy link
Member

@zygoloid , any opinion here?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants