[basic.lval] Non-static member function designator is a prvalue CWG2458

[languagelawyer]

[expr.ref]/6.3.2:

if E1.E2 refers to a non-static member function and the type of E2 is “...”, then E1.E2 is a prvalue. The expression designates a non-static member function.

[zygoloid]

Hm, non-static member functions really don't fit into the value category taxonomy well at all. We do seem to be consistent, at least; [expr.prim.id.qual]/2 also says that Class::f is a prvalue if f is a non-static member function.

I don't like complicating the definition of lvalue with this quirk (and note that we'd need to complicate the definition of prvalue with it too), so since it makes no observable difference, I'd like to first send this to CWG to see if we can reclassify non-static member function expressions as lvalues. That should simplify the wording: we get a simpler rule here, we get a simpler rule in [expr.prim.id.qual]/2, we get a simpler rule in [expr.ref] (all of /6.3 produces an lvalue). And we get a simpler rule for the & operator: it always wants an lvalue as its operand.

We may still want a change here if we go that route:

A \defn{glvalue} is an expression whose evaluation determines the identity of an object, bit-field, or function, or both an object and a non-static member function.

[languagelawyer]

@zygoloid:

and note that we'd need to complicate the definition of prvalue with it too

Why? [expr.ref]/6.3.2 says:

The expression designates a non-static member function. The expression can be used only as the left-hand operand of a member function call

And the definition of prvalue says:

A prvalue is an expression whose evaluation ... computes the value of an operand of an operator

I've thought this "computes the value of an operand of an operator" is enough to cover non-static member function designators usage. ("value" does not apply well, though).

UPD: Ah, you mean that E1.E2 denotes (or rather should denote) both a non-static member function and an object. Then prvalue definition would indeed need a fix.
However, currently [expr.call] is worded as if it decomposes E1.E2 and looks at E1 (the object expression).

[languagelawyer]

I'd like to first send this to CWG to see if we can reclassify non-static member function expressions as lvalues

Should I send this?

[jensmaurer]

http://lists.isocpp.org/core/2020/07/9540.php

[jensmaurer]

@languagelawyer: Now that CWG2458 has landed, could you please update the pull request accordingly?

[languagelawyer]

@jensmaurer rate the ugliness