CWG2902 Use of id-expressions denoting explicit object member functions is too permissive

[brevzin]

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

Reference (section label): Unknown

Link to reflector thread (if any): None

Issue description: There is implementation divergence in the following example:

struct C {
    int f(this C);
};

using T = decltype(C::f); // #1
int g = C::f(42); // #2

For #1, MSVC currently accepts, gcc reject and clang reject. Our current wording, I think, allows this by way of the P2797's change to [expr.prim.id.general]'s limits of when to use an id-expression that denotes a non-static member or non-static member function to only apply to implicit object member functions. However, that change doesn't seem related to the rest of the paper and the design intent of P0847 was to reject such usage.

For #2, all compilers current reject, but I think the [expr.prim.id.general] relaxation might actually allow it. I'm not sure if there is any other rule that forbids it, but we do want to disallow this case.

[ranaanoop]

This seems to be a dupe/related to the already posted issue: [basic.compound] Current wording seems to disallow formation of pointer to static member function and explicit object member function without & operator.

[jensmaurer]

CWG2902 is rewriting that particular section of [expr.prim.id.general]. Looks like the case "naming an explicit object member function" (outside of a class member access or unary & or the implicit-this transformation) should just be ill-formed.

@brevzin , what do you think?

[brevzin]

Looks like the case "naming an explicit object member function" (outside of a class member access or unary & or the implicit-this transformation) should just be ill-formed.

Yeah that was our intent with the design/wording. Both #1 and #2 above should be ill-formed. This is part of why we wanted to call an explicit object member function a non-static member function.

[jensmaurer]

Folded into CWG2902.