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
An expression E is a core constant expression unless the evaluation of E, following the rules of the abstract machine ([intro.execution]), would evaluate one of the following:
[...]
5.8 an lvalue-to-rvalue conversion unless it is applied to
a non-volatile glvalue that refers to an object that is usable in constant expressions, or
a non-volatile glvalue of literal type that refers to a non-volatile object whose lifetime began within the evaluation of E;
[...]
5.12 an id-expression that refers to a variable or data member of reference type unless the reference has a preceding initialization and either
it is usable in constant expressions or
its lifetime began within the evaluation of E;
Consider this example:
structA{
intconst& rf;
};
constexprint value = 10;
A a{value};
constexprint v = a.rf; // error
a.rf does refer to the object value that is usable in constant expressions. The only possible reason why the initialization is not a constant expression should be 5.12. The wording of 5.12 is changed in the current draft, however, which has a similar meaning for this case.
[expr.const] p7
For such a reference that is not usable in constant expressions, the reference is treated as binding to an unspecified object of the referenced type whose lifetime and that of all subobjects includes the entire constant evaluation and whose dynamic type is constexpr-unknown.
So, this issue remains that whether the evaluation of the class member access would evaluate the id-expression. [expr.ref] p1 says
The postfix expression before the dot or arrow is evaluated; the result of that evaluation, together with the id-expression, determines the result of the entire postfix expression.
It is a bit vague whether the id-expression is evaluated. The improvement might be
The postfix expression before the dot or arrow is evaluated; the result of that evaluation, together with the evaluation of the id-expression, determines the result of the entire postfix expression.
The change makes the implied meaning clearer.
Another issue is, whether we admit that the post-expression in the class member access is sequenced before the id-expression
The text was updated successfully, but these errors were encountered:
The id-expression in a class member access is a compile-time thing and "evaluating" it doesn't make much sense; it doesn't have a "value" by itself. Only in conjunction with the object expression does it have a value.
In the c++20 document, [expr.const p5 says
Consider this example:
a.rf
does refer to the objectvalue
that is usable in constant expressions. The only possible reason why the initialization is not a constant expression should be 5.12. The wording of 5.12 is changed in the current draft, however, which has a similar meaning for this case.[expr.const] p7
So, this issue remains that whether the evaluation of the class member access would evaluate the id-expression. [expr.ref] p1 says
It is a bit vague whether the id-expression is evaluated. The improvement might be
The change makes the implied meaning clearer.
Another issue is, whether we admit that the post-expression in the class member access is sequenced before the id-expression
The text was updated successfully, but these errors were encountered: