Created on 2020-07-04.00:00:00 last changed 7 months ago
Proposed resolution (April, 2021):
Change 184.108.40.206 [expr.prim.id.qual] paragraph 5, converting the running text into a bulleted list, as follows:
The result of a qualified-id is the entity it denotes (6.5.5 [basic.lookup.qual]). The type of the expression is the type of the result. The result is an lvalue if the member is
a function ,
a structured binding (9.6 [dcl.struct.bind]),
a static member function, or
a data member,
and a prvalue otherwise.
Change 220.127.116.11 [expr.unary.op] paragraph 3 as follows:
The result of theunary & operator is a pointer to its operand.
If the operand is a qualified-id naming a non-static or variant member m of some class C
with type T, the result has type “pointer to member of class C of type T” and is a prvalue designatingC::m.
if the operand is an lvalue of type T,the resulting expression is a prvalue oftype “pointer to T” whose result is a pointerto the designated object (6.7.1 [intro.memory]) or function . [Note 2: In particular, taking the address of a variable of type “cv T” yields a pointer of type “pointer to cv T”. —end note]
Otherwise, the program is ill-formed.
[Drafting note: neither 18.104.22.168 [expr.ref] bullet 6.3.2,
Otherwise (when E2 refers to a non-static member function), E1.E2 is a prvalue. The expression can be used only as the left-hand operand of a member function call (11.4.2 [class.mfct]). [Note 5: Any redundant set of parentheses surrounding the expression is ignored (7.5.3 [expr.prim.paren]). —end note]
nor 7.6.4 [expr.mptr.oper] paragraph 6,
...The result of a .* expression whose second operand is a pointer to a member function is a prvalue...
requires any change.]
Notes from the August, 2020 teleconference:
CWG preferred that the unbound case (i.e., &X::f) should be an lvalue, while the bound case should be a prvalue.
[Accepted as a DR at the June, 2021 meeting.]
Expressions denoting non-static member functions are currently classified as prvalues (22.214.171.124 [expr.prim.id.qual] paragraph 2; 126.96.36.199 [expr.ref] bullet 6.3.2; and 7.6.4 [expr.mptr.oper] paragraph 6). It would simplify the specification if such expressions were categorized as lvalues. (See also this pull request.)
|2021-11-15 00:00:00||admin||set||messages: + msg6583|
|2021-11-15 00:00:00||admin||set||status: drafting -> drwp|
|2020-12-15 00:00:00||admin||set||messages: + msg6234|