一元*运算符的操作数是否期望纯右值

Question

int main(){
  int a = 0;
  auto ptr = &a;
  auto&& rf = *ptr;
}

Consider the above code, when glvalue ptr is used to as the operand of unary* operator, Is it be required a lvalue-to-rvalue conversion that would applied for it? IE, Does the operand of unary* operator expect a prvalue?

Question 1:

expr.unary.op#1

The unary * operator performs indirection: the expression to which it is applied shall be a pointer to an object type, or a pointer to a function type and the result is an lvalue referring to the object or function to which the expression points. If the type of the expression is “pointer to T”, the type of the result is “T”. [ Note: Indirection through a pointer to an incomplete type (other than cv void) is valid. The lvalue thus obtained can be used in limited ways (to initialize a reference, for example); this lvalue must not be converted to a prvalue, see [conv.lval]. — end note ]

What kind of value categories does operands of unary* operator expect.

---

Beside this operator, It seems to the most operators in [expr] is not specified what kind of value categories its operands expect.

expr#9

Whenever a glvalue expression appears as an operand of an operator that expects a prvalue for that operand, the lvalue-to-rvalue, array-to-pointer, or function-to-pointer standard conversions are applied to convert the expression to a prvalue. [ Note: Because cv-qualifiers are removed from the type of an expression of non-class type when the expression is converted to a prvalue, an lvalue expression of type const int can, for example, be used where a prvalue expression of type int is required. — end note ].

The quote above is so unclear.

Question 2:

As aforementioned, the most operators in [expr] is not specified what kind of value categories its operands expect. So It it a defect?

Answer 1

In general, it is CWG1642 :

1642. Missing requirements for prvalue operands

Although the note in 6.10 [basic.lval] paragraph 1 states that

The discussion of each built-in operator in Clause 8 [expr] indicates the category of the value it yields and the value categories of the operands it expects

in fact, many of the operators that take prvalue operands do not make that requirement explicit. Possible approaches to address this failure could be a blanket statement that an operand whose value category is not stated is assumed to be a prvalue; adding prvalue requirements to each operand description for which it is missing; or changing the description of the usual arithmetic conversions to state that they imply the lvalue-to-rvalue conversion, which would cover the majority of the omissions.

In particular, [expr.unary.op]/1 wording should be fixed by this PR .