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.constexpr] Uninitialized non-static data members of fundamental type CWG2558 #5422
Comments
https://cplusplus.github.io/CWG/issues/2536.html seems related. |
This is CWG2558. |
If the omission will be identified to be an accident, the proposed wording might be that add an item in [expr.const] p5, which is:
|
It was intentional that we can have core constant expressions with undefined data. We might not want to have undefined results when initializing a constexpr variable, though. See the issue cross-linked in CWG2558 for details. |
No. What you suggested is partially reverting P1331R2, i.e. still disallowing trivial default initialization in constant evaluation while just allowing them in I think the resolution would be like this (added to [expr.cons]/11):
|
That is what the implementations do here. I'm not seeing the wording in P1331R2 that supports this behavior. If we want to augment [expr.cons]/11 to fix this issue. I think [expr.cons]/11 should first be clarified since the wording is not clear
How could the value be an object? At least, an object can have a lifetime, how could the value of a prvalue have? |
Implementations do allow it. See here. In this example, constexpr int foo = []{
int x;
x = 42;
return x;
}();
I suspect that using "object" may be OK here, as the prvalue will eventually be materialized. Perhaps the key problem is lack of a term corresponding to "subobject", in order to specify a sub-portion of a prvalue. |
If we discussed any object in a prvalue, the design of prvalue is meaningless. Again, an object occupy storage, prvalue does not. To clarify this point, we might say
|
The part for CWG2558 is resolved (a union value without an active member can be a constant expression, while an indeterminate scalar value can't). But it's still a bit weird to say a subobject of a prvalue.
I think it's safe to check the result object, since in contexts needing to determine whether a expression of a class or array type is a constant expression, the result object must exist. It might be better to replace the occurence of "the value" with "the result object", not sure whether this is editorial. |
Consider this example
In C++17 standard, we have the restriction on the constructor that is declared with
constexpr
. [dcl.constexpr] p4Since the member
value
does not have a default initializer or specified its initialization with the mem-initializer, thus its default initialization performs no initialization. From this perspective, we can justify that#1
is ill-formed. However, in the current draft, we do not have this restriction anymore, and I do not find any replaceable rules. The full-expression of the initialization does not violate [expr.const] p5 nor [expr.const] p11, however, the example is rejected by all implementations. The reason for the rejection is basically:We do not have the restrictions in either [dcl.constexpr] or [expr.const]. Is the revision of the draft omit the restriction?
The text was updated successfully, but these errors were encountered: