例如，第 3.10/1 段中的注释说:

第 5 条中对每个内置运算符的讨论指出了它产生的值的类别以及它期望的操作数的值类别.例如，内置赋值运算符期望左操作数是左值，右操作数是右值并产生左值作为结果. 用户定义的运算符是函数，类别它们期望和产生的值由它们的参数和返回类型决定

The discussion of each built-in operator in Clause 5 indicates the category of the value it yields and the value categories of the operands it expects. 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. User-defined operators are functions, and the categories of values they expect and yield are determined by their parameter and return types

另一方面，关于赋值运算符的第 5.17 节没有提到这一点.但是，在注释(第 5.17/1 段)中再次提到了执行左值到右值转换的可能性:

因此，函数调用不应干预左值到右值的转换和与任何单个复合赋值运算符相关的副作用

Therefore, a function call shall not intervene between the lvalue-to-rvalue conversion and the side effect associated with any single compound assignment operator

当然，如果不期望右值，则此注释将毫无意义.

另一个证据是在 4/8 中发现的，正如 Johannes Schaub 在对链接问答:

在某些情况下，某些转换会被抑制.例如，不在一元 & 的操作数上进行左值到右值的转换.操作员.在这些运算符和上下文的描述中给出了特定的例外情况.

There are some contexts where certain conversions are suppressed. For example, the lvalue-to-rvalue conversion is not done on the operand of the unary & operator. Specific exceptions are given in the descriptions of those operators and contexts.

这似乎意味着对内置运算符的所有操作数都执行左值到右值的转换，除非另有说明.这意味着，除非另有说明，否则右值应作为内置运算符的操作数.

推测:

尽管初始化不是赋值，因此操作符没有进入讨论，但我怀疑规范的这一领域受到上述相同问题的影响.

甚至可以在第 8.5.2/5 段中找到支持这种信念的痕迹，关于引用的初始化(对于它来说不需要左值初始化表达式的值):

int y;
int x = y; // No UB
short t;
int u = t; // UB! (Do not like this non-uniformity, but could accept it)
int z;
z = x; // No UB (x is not uninitialized)
z = y; // UB! (Assuming assignment operators expect a prvalue, see above)
       // This would be very counterintuitive, since x == y

int y = 0;
int x = y; // y is lvalue, prvalue expected (assuming the conjecture is correct)

          | A2 = Yes   | A2 = No |
 ---------|------------|---------|
 A1 = Yes |     UB     |  No UB  | 
 A1 = No  | ill-formed |  No UB  |
 ---------------------------------