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] Remove confusing ‘no initialization’ from default-initialization and zero-initialization #4910
Comments
Wrong. Its lifetime begins when storage is obtained, and initialization if any is complete. If no initialization occurs, the lifetime still begins. |
Because zero-initialization is a blanket term for several different effects, depending on the type. One of those is "no initialization". It's not terribly important for a reference anyway, because that would be ill-formed (references must be bound to something). Please use stack overflow for help reading the wording, not this issue tracker. |
Alright. In other words:
Correct? |
This is not the C++ help desk. |
No. |
Alright, I have just asked the question here since it is more appropriate: |
From [dcl.init.general/7] (bold emphasis mine):
How can a scalar object be at the same time default-initialized and not initialized?
For instance consider this program:
From [dcl.init.general/11]:
So
i
is default-initialized.From [basic.life/1]:
So
i
is a vacuous initialization and therefore its lifetime begins. Yeti
is uninitialized so its lifetime does not begin.Therefore I suggest we reword [dcl.init.general/7] from
to
That way scalar types are not in two different states at the same time.
Same remark for [dcl.init.general/6] (bold emphasis mine):
How can a reference be at the same time zero-initialized and not initialized?
Therefore I suggest we reword [dcl.init.general/6] from
to
The text was updated successfully, but these errors were encountered: