The way "discarded-value expression" is described in the standard.

[Yar Izdum]

"In some contexts, an expression only appears for its side effects. Such an expression is called a discarded-value expression."

Then, under "Expression Statements":
"Expression statements have the form:
expression-statement:
    expression(optional);

The expression is a discarded-value expression..."

But... this is an expression statement:

5 + 5;

And it doesn't have a side effect, which doesn't fit the definition of discarded-value expression...

Should it be, instead, "The expression may be a discarded-value expression..."
Am I just picking nits?
And isn't the temporary used to hold the result of an expression always discarded at the end of the expression, anyway?

[Johannes Schaub]

Determining whether an expression statement induces a side effect or not in general cannot be done at conpile time. Even calling function is not necessarily a side effect.

The major point is that a discarded value expression... discards its value. I guess the description is intended to say "an expression only appears for its potential side effects".

But if I were to really split hairs, note that it says "such an expression is called a discarded-value expression". It does not say "Some expressions are discarded-value expressions. Such expressions only appear for their side effects".

The point of the classification is an introduction of a temporary in the first place. Otherwise prvalues would be without a result object.

[Yar Izdum]

On Sunday, September 11, 2016 at 6:52:06 AM UTC-4, Johannes Schaub wrote:

Determining whether an expression statement induces a side effect or not in general cannot be done at conpile time. Even calling function is not necessarily a side effect.

The major point is that a discarded value expression... discards its value. I guess the description is intended to say "an expression only appears for its potential side effects".

But if I were to really split hairs, note that it says "such an expression is called a discarded-value expression". It does not say "Some expressions are discarded-value expressions. Such expressions only appear for their side effects".

The point of the classification is an introduction of a temporary in the first place. Otherwise prvalues would be without a result object.

Hm. Let me ask you a question, then... because I thought every expression discarded its value at the end of the expression (or end of the statement, or after a comma operator, etc.). In an assignment expression statement, such as: int x = 5 + 5; Does the temporary 10 "bind" to x, rather like this statement? int &&x = 5 + 5;
Or is the value 10 simply copied into x, and then discarded? (which is what I have believed for years, sadly).

[David Krauss]

> On 2016–09–11, at 7:49 PM, Yar Izdum <jeremywa...@gmail.com> wrote:
>
> Hm. Let me ask you a question, then... because I thought every expression discarded its value at the end of the expression (or end of the statement, or after a comma operator, etc.). In an assignment expression statement, such as: int x = 5 + 5; Does the temporary 10 "bind" to x, rather like this statement? int &&x = 5 + 5;
> Or is the value 10 simply copied into x, and then discarded? (which is what I have believed for years, sadly).

This recently changed with guaranteed copy elision. Previously, the initializer was represented by a temporary object, which could (by optional copy elision) be eliminated and replaced by the declared variable. Currently, the initializer prvalue is backed directly by the declared variable.

Of course, there’s no distinction for primitive types like int. There’s only an observable difference when a nontrivial constructor could be used.