[intro.execution] How is the value computation that computes the result of an operator sequenced with the evaluation that initializes an object

[xmh0511]

Full name of submitter (unless configured in github; will be published with the issue): Jim X

Consider this example:

int main(){
  int a =1, b=2;
  int c = a + b;
}

The evaluation of the expression a+b, IIUC, will comprise these sub-evaluations:

1. the value computation of a, let's call it A
2. the value computation of b, let's call it B
3. the value computation that computes the result of the operator +, let's call it S
4. the evaluation that initializes the result object c, let's call it I

We do have a rule that specifies the sequence between the first three evaluations; that is, [intro.execution] p10

The value computations of the operands of an operator are sequenced before the value computation of the result of the operator.

However, we seem not to explicitly specify how S is sequenced with I. Intuitively, the computed result value should be stored into the context of the prvalue as its result as per [basic.lval] p5

The result of a prvalue is the value that the expression stores into its context;

It's reasonable that S should be sequenced before I; however, two evaluations will be unsequenced if there is no explicit specification.

Suggested Resolution:

[t3nsor]

S and I are not separate evaluations. They are a single evaluation. a + b is a prvalue. The "value computation of the result" is merely another way of describing the last step in the evaluation of that prvalue, the one that takes place after the value computations of the operands. But as soon as the prvalue is evaluated, c has been initialized ([basic.lval]/1.2).

[xmh0511]

S and I are not separate evaluations. They are a single evaluation. a + b is a prvalue. The "value computation of the result" is merely another way of describing the last step in the evaluation of that prvalue, the one that takes place after the value computations of the operands. But as soon as the prvalue is evaluated, c has been initialized ([basic.lval]/1.2).

I think it highlights a fundamental ambiguity in the current specification: what formally defines the boundaries of an "evaluation", and what rules dictate whether two actions are separate evaluations or a single one?

From the perspective of the prvalue expression a + b, all three steps—A (value computation of a), B (value computation of b), and S (value computation of +)—are contained within the overall evaluation of a + b. Yet, [intro.execution] p10 explicitly treats A/B and S as distinct, individual evaluations that are sequenced relative to each other (A and B are sequenced before S).

If A, B, and S can be decomposed into separate evaluations despite all belonging to the evaluation of a + b, why should S (computing the result value) and I (initializing the result object c) suddenly be treated as a monolithic, indivisible evaluation? They perform conceptually distinct operations—S computes the value, whereas I carries out the initialization.

It seems the standard currently lacks explicit criteria for decomposing expressions and initializations into discrete evaluation units. Without a clear specification of how evaluation granularity is defined, asserting that two actions are "a single evaluation" versus "separate evaluations" relies on intuitive interpretation rather than standard text. This lack of formal boundary definition is precisely why we need an explicit sequencing rule (or a clearer definition of evaluation granularity) between S and I.

[t3nsor]

why should S (computing the result value) and I (initializing the result object c) suddenly be treated as a monolithic, indivisible evaluation? They perform conceptually distinct operations—S computes the value, whereas I carries out the initialization.

Because the first one doesn't exist within the model of the abstract machine. There's no kind of evaluation step that is a platonic determination by the implementation that the mathematical result is 3. If you think there is, then explain how the standard supports your belief?

The 3 that's actually produced by the evaluation (as opposed to 3 that is merely a potential value, i.e., an element of the representable range of int) has no existence other than as the result of a prvalue.

[xmh0511]

why should S (computing the result value) and I (initializing the result object c) suddenly be treated as a monolithic, indivisible evaluation? They perform conceptually distinct operations—S computes the value, whereas I carries out the initialization.

Because the first one doesn't exist within the model of the abstract machine. There's no kind of evaluation step that is a platonic determination by the implementation that the mathematical result is 3. If you think there is, then explain how the standard supports your belief?

The 3 that's actually produced by the evaluation (as opposed to 3 that is merely a potential value, i.e., an element of the representable range of int) has no existence other than as the result of a prvalue.

I think the assertion that "the value computation of the result does not exist as an evaluation step within the abstract machine" directly contradicts the explicit terminology and sequencing rules defined in [intro.execution].

The standard supports the formal existence of this evaluation step through the following chain of specifications:

1. Value computations ARE evaluations:
   [intro.execution] explicitly defines what an evaluation is:

   Evaluation of an expression (or subexpression) in general includes both value computations [...] and initiation of side effects.

2. The "value computation of the result" is explicitly named and sequenced:
   [intro.execution] p10 states:

   The value computations of the operands of an operator are sequenced before the value computation of the result of the operator.

   If "the value computation of the result of the operator" were a non-existent concept or not an evaluation step in the abstract machine, [intro.execution] p10 could not meaningfully establish a sequencing relation (sequenced before) on it. In C++, sequencing is strictly a relation between evaluations ([intro.execution] p7).

3. The semantic content of this computation is explicitly specified:
   [expr.add] p3 defines what this value computation actually computes:

   The result of the binary + operator is the sum of the operands.

Dismissing the value computation of the operator as "non-existent" ignores [intro.execution] p1 and p10. If it exists enough to be sequenced after its operands, its sequencing relationship with the rest of the initialization process should also be rigorously defined.

[t3nsor]

The value computation of the result is the last step in the evaluation of the prvalue result (at least in this case where you're adding two ints). I never said that it doesn't exist; I said that what does not exist is a separate step in which the implementation determines the mathematical sum, but does not yet produce the prvalue result. Your responses appear to misunderstand this point, and to be honest, they read as AI-generated, which I find incredibly disrespectful.

[xmh0511]

The value computation of the result is the last step in the evaluation of the prvalue result (at least in this case where you're adding two ints). I never said that it doesn't exist; I said that what does not exist is a separate step in which the implementation determines the mathematical sum, but does not yet produce the prvalue result. Your responses appear to misunderstand this point, and to be honest, they read as AI-generated, which I find incredibly disrespectful.

Sorry, English is not my native language, so I relied on an LLM to help refine my phrasing and grammar, which resulted in an overly formal and artificial tone. I deeply respect your time and expertise, and I did not mean to be disrespectful.

However, I don't think the action "initialize a result object" is a kind of value computation, or vice versa. Since [intro.execution] p10 separately mentions the value computation of the result of the operator, this should be viewed as an individual evaluation, just like A and B are. I don't know why you used "produce the prvalue result"? Isn't the whole expression a+b the prvalue whose result is 3?

Or do you mean all these evaluations(i.e., A, B, S) are the constituent evaluations of the evaluation that "initializes a result object"? So, any of these three cannot be ordered with the containing evaluation(i.e., "initializes a result object")?

[t3nsor]

In [expr.compound] we often use phrasing like "the result is a prvalue". Apparently, we failed to say that explicitly in [expr.add]; it should probably be in there (I believe there is already a separate thread about this). So we have the following situation: the result---which is the thing that the value computation is computing---is a prvalue, and that prvalue also has its own result, also known as its value ([basic.lval]/5). It's a bit unfortunate that the term is overloaded, but I think we'll survive.

So "value computation of the result of the operator" means value computation of a prvalue (since the result of the operator is a prvalue). And what does value computation of a prvalue mean? According to [basic.lval]/5:

The result of a prvalue is the value that the expression stores into its context [...] A prvalue whose result is the value V is sometimes said to have or name the value V.

The second sentence tells us that we can substitute "value" for "result" in the first sentence. In other words you can read the first sentence as if it says: "The value of a prvalue is the value that the expression stores into its context." Observe that this sentence is in present tense; it doesn't say: "the value of a prvalue is the value that the expression will store into its context". The possession of a value by a prvalue expression is therefore indivisible from the action of the prvalue in which the value is stored into its context (in this case meaning the initialization of c).

And so, the "value computation of the result of the operator", i.e., the value computation of the prvalue, necessarily also stores that value into the context.

[xmh0511]

Apparently, we failed to say that explicitly in [expr.add]; it should probably be in there (I believe there is already a separate thread about this).

This is the subject of CWG2981. I also posted the relevant issue #966 about why saying the result is a prvalue here. As per [basic.lval], only expressions can have value categories; does it mean the result of the operator is an expression because it's a prvalue?

Then, what's the relationship between the original whole expression a+b and the result of the operator +? As per your explanation here

the result---which is the thing that the value computation is computing---is a prvalue

Is the latter a new non-lexical expression produced by the evaluation of the former? Or is the result(an expression) a subexpression of the former?

The possession of a value by a prvalue expression is therefore indivisible from the action of the prvalue in which the value is stored into its context (in this case meaning the initialization of c).

Do you mean the evaluation of the expression a+b produces the result of the operator(named R), which is a prvalue, and it naturally has the value 3 when the prvalue is produced. [expr.add] p3

The result of the binary + operator is the sum of the operands.

merely abstractly specifies the value as the value of the prvalue(the result of the operator). In other words, the process of the mathematical computation(i.e., getting 3 from 1+2) is not considered as part of the evaluation of either expression a+b or the result prvalue?

[safocl]

The terminology of the [basic.exec] section appears to be specific to its needs. However, only indirect connections to terminology in other sections are intentionally indicated, such as "every value computation and every side effect associated with the expression X" ("associated") and the like.

[t3nsor]

"The result is a prvalue" is just another way of saying that the expression is a prvalue, while "The result [...] is the sum of the operands" is another way of saying that the result/value of that prvalue is the sum of the operands.

So, let's go back to the phrase the "value computation of the result". If "result" here meant the value, then the phrase would simply be "computation of the result", as it would be redundant to say "value" again. Therefore, we should interpret it as meaning the value computation of the prvalue.

Because the entire expression a + b is a prvalue, but evaluating that expression involves the "preliminary" steps of reading the values of a and b, we need a way to refer to the final step in the evaluation of that prvalue. That's what the value computation is.

As I mentioned before, when evaluation of the prvalue is complete, the initialization of c is also necessarily complete (because of [basic.lval]/1.2). So, to answer the question of whether the initialization of c involves one last execution step that is separate from the "value computation", it suffices to answer the question of how many execution steps there are in the evaluation of the prvalue.

As I mentioned before, I do not consider the use of the term "value computation" to refer to a second-last execution step in the evaluation of the prvalue. The standard gives us no reason to believe that there is such an execution step. You seem to be under the impression that because the standard has rules defining the sequencing of value computation execution steps with respect to other execution steps, it means that "value computation" is a unique kind of execution step, i.e., one that is distinct from other possible execution steps such as storing the initial value into c. I just don't find that argument convincing at all. It seems to me that we should not infer the existence of additional execution steps merely based on the terminology used to describe them. The presumption should be that the standard does not mean to convey the existence of additional execution steps unless it does so clearly.

[xmh0511]

"The result is a prvalue" is just another way of saying that the expression is a prvalue

Consider this a bit complex example:

int a =0, b=1;
a++ +b; // #1

IIUC, first, the modification to a is associated evaluation of the evaluation of the expression at #1.

We say the expression #1 is a prvalue; however, according to the definition of a prvalue(i.e., basic.lval]/1.2), whose evaluation does actions as follows:

1. initializes an object
2. computes the value of an operand of an operator

However, according to the definition of an evaluation

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.

That is, the modification(a kind of side effect) shouldn't be subsumed under value computation. However, the modification to a as the step of the evaluation of the prvalue(i.e., expression #1) does the action that is not mentioned in basic.lval]/1.2.

---

It seems to me that we should not infer the existence of additional execution steps merely based on the terminology used to describe them.

This is the issue I mentioned in another thread(#959). The current wording seems not to formally define which evaluations are considered constituent sub-evaluations of an evaluation, whether or when they are viewed as a separate evaluations that can be used to be ordered with other sub-evaluations

[safocl]

If "result" here meant the value, then the phrase would simply be "computation of the result", as it would be redundant to say "value" again.

Let me add that, in my opinion, this is directly confirmed by the provisions of the standard at [basic.lval#5]

[t3nsor]

Consider this a bit complex example:

int a =0, b=1;
a++ +b; // #1

Here, the value computation is the step that initializes the discarded int object with the value 1. The side effect on a may happen before, after, or concurrently with that step. The basic idea remains the same.

This is the issue I mentioned in another thread(#959). The current wording seems not to formally define which evaluations are considered constituent sub-evaluations of an evaluation, whether or when they are viewed as a separate evaluations that can be used to be ordered with other sub-evaluations

Feel free to contribute improved wording.

[safocl]

Here, the value computation is the step that initializes the discarded int object with the value 1. The side effect on a may happen before, after, or concurrently with that step. The basic idea remains the same.

It is possible to add a comment (notes) at the very beginning of this section or subsection ([intro.execution]) that

"this section only describes the order of execution, the dependencies of execution operations among themselves and the requirements for execution in the implementation"

, that

"this section does not define the operation of the abstract machine itself and its terminology"

(or something like that), will be able to prevent future questions about the wording itself, which in the context of these aspects seems quite normal, but which, if not distinguished from other sections of the standard, may seem confusing with other provisions.