[expr] The clauses of some operators lack the specification of the type and value category of the result of the operator

[xmh0511]

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

In [intro.execution] p10, the rule says

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

In [basic.lval] note1, the wording implies that the result of the operator is the result of the expression associated with the operator

For example, the built-in assignment operators expect that the left operand is an lvalue and that the right operand is a prvalue and yield an lvalue as the result.

However, in some operator clauses, we lack a specification of the result's type and value category. For example, [expr.add] p3

The result of the binary + operator is the sum of the operands. The result of the binary - operator is the difference resulting from the subtraction of the second operand from the first.

It didn't specify the value category of the result of the operator. By contrast, [expr.comma] explicitly specifies all of them

The type and value of the result are the type and value of the right operand; the result is of the same value category as its right operand, and is a bit-field if its right operand is a bit-field.

Suggested Resolution:

Explicitly specify type, value, and value category for all operators if the corresponding clauses miss the specification.

[jensmaurer]

I thought I've seen something like this concern before.

Do you have a complete list where we're lacking? Isn't [expr.arith.conv] already covering a lot of ground here?

[xmh0511]

I thought I've seen something like this concern before.

Isn't [expr.arith.conv] already covering a lot of ground here?

[expr.arith.conv] only covers the type of the result

The purpose is to yield a common type, which is also the type of the result.

However, it doesn't explicitly specify what the value category of the result is.

Do you have a complete list where we're lacking?

For example, the unary operators +, -, and ~, [expr.mptr.oper], [expr.bit.and] and so on, don't specify the value category of the result of the operator

[expr.pre.incr], [expr.new], and [expr.delete] don't mention the result of the operator at all.

[expr.ref] p8 uses a different description to specify the value category

If E2 designates an entity that is declared to have type “reference to T”, then E1.E2 is an lvalue of type T.

We may need to uniformly use "the result of the operator".

[eisenwave]

Sort of related:

• CWG2981 [expr.arith.conv] 0 < 0 is an int #663
• CWG2981

Seems like that issue is giving us an explicit type and value category for a bunch of those operators.