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

[intro.execution] p7 value computation vs. prvalue #5477

Open
xmh0511 opened this issue May 19, 2022 · 2 comments
Open

[intro.execution] p7 value computation vs. prvalue #5477

xmh0511 opened this issue May 19, 2022 · 2 comments

Comments

@xmh0511
Copy link
Contributor

xmh0511 commented May 19, 2022

[intro.execution] p7 says

Evaluation of an expression (or a subexpression) in general includes both value computations (including determining the identity of an object for glvalue evaluation and fetching a value previously assigned to an object for prvalue evaluation) and initiation of side effects.

Consider the sentence in the parenthesis

determining the identity of an object for glvalue evaluation

This is exact the definition of glvalue per [basic.lval] p 1.1

A glvalue is an expression whose evaluation determines the identity of an object or function.

It could be understood that the evaluation of a glvalue is a kind of value computation. However, the emphasized part is a bit strange:

fetching a value previously assigned to an object

This sounds like the duty of the lvalue-to-rvalue conversion. What if an expression itself is a prvalue(e.g. 0 + int{1};)? Shall we just say

fetching the value of a prvalue for prvalue evaluation(i.e. computes the value of an operand of an operator)

This is one function of the evaluation of prvalue

A prvalue is an expression whose evaluation computes the value of an operand of an operator, as specified by the context in which it appears

It is not sure whether the initialization of the result object of a prvalue takes account to be the value computation? After all, we just define the side effect as

Reading an object designated by a volatile glvalue ([basic.lval]), modifying an object, calling a library I/O function, or calling a function that does any of those operations are all side effects

We define "modifying an object" with the cross-reference to ([expr.ass], [expr.post.incr], [expr.pre.incr]), in [dcl.type.cv]

Any attempt to modify ([expr.ass], [expr.post.incr], [expr.pre.incr]) a const object

however, they are not about initialization.

@frederick-vs-ja
Copy link
Contributor

fetching a value previously assigned to an object for prvalue evaluation

This part seemly only covers lvalue-to-rvalue conversion, which is a bit problematic.

however, they are not about initialization.

Initialization is not modification, although IMO explicitly creating an object within a byte array should also contain modifications...

Is this part touching the same issue as cplusplus/CWG#38?

@xmh0511
Copy link
Contributor Author

xmh0511 commented May 20, 2022

This part seemly only covers lvalue-to-rvalue conversion, which is a bit problematic.

IMO, a prvalue should be a pure prvalue even though it was a glvalue before applying lvalue-to-rvalue conversion. Since an expression is either a glvalue: {lvalue, xvalue}, or prvalue, the evaluation of the expression is either the evaluation of them. I wonder should we consider the lvalue-to-rvalue conversion as a part of the evaluation of a prvalue? I think [basic.lval] p1 says it shouldn't be. The evaluation of a prvalue is based on that the expression has been a prvalue. However, this opinion obviously contradicts [expr.const] p5.9

an lvalue-to-rvalue conversion unless it is applied to

which consider the lvalue-to-rvalue conversion as a part of evaluation of a prvalue.

constexpr int v = a;

the converted a(that is a prvalue) is used to initialize v, which is the duty of evaluation of a prvalue. However, the rule implies that it should consider the lvalue-to-rvalue conversion in the initialization.


Is this part touching the same issue as cplusplus/CWG#38?

we all agree the initialization of an object is not a side effect. This issue just claims to clarify value computation and whether lvalue-to-rvalue is considered to be part of the evaluation of a prvalue.

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