Why the sentence "The expression can be used only as the left-hand operand of a member function call" in [expr.ref]p(6.3.2)?

Question

[expr.ref]p(6.3.2):

Otherwise, if E1.E2 refers to a non-static member function and the type of E2 is “function of parameter-type-list cv ref-qualifier_opt returning T”, then E1.E2 is a prvalue. The expression designates a non-static member function. The expression can be used only as the left-hand operand of a member function call ([class.mfct]). [ Note: Any redundant set of parentheses surrounding the expression is ignored ([expr.prim.paren]). — end note ] The type of E1.E2 is “function of parameter-type-list cv returning T”.

For example the second statement in main below doesn't compile, probably because of the highlighted sentence above. But why is the language set up to work this way?

#include<iostream>
void g();
struct S { void f(); };
S s;

int main(){
    std::cout << "decltype(g) == void() ? " << std::is_same<decltype(g), void()>::value << '\n';            // Ok
    std::cout << "decltype(s.f) == void() ? " << std::is_same<decltype(s.f), void()>::value << '\n';        // Doesn't compile probably because of the sentence hihlighted above in [expr.ref]p(6.3.2).
}

Answer 1

When you do E1.E2, you are not talking about a general property of the type of thing that E1 is. You're asking to access a thing within the object designated by E1, where the name of the thing to be accessed is E2. If E2 is static, it accesses the class static thing; if E2 is non-static, then it accesses the member thing specific to that object. That's important.

Member variables become the subobject. If your class S had a non-static data member int i;, s.i is a reference to an int. That reference, from the stand point of an int&, behaves no differently from any other int&.

Let me say that more clearly: any int* or int& can point to/reference an int which is a complete object or an int which is a subobject of some other object. The single construct int& can serve double-duty in this way.^*

Given that understanding of s.i, what would be the presumed meaning of s.f? Well, it should be similar, right? s.f would be some kind of thing that, when called with params, will be the equivalent of doing s.f(params).

But that is not a thing which exists in C++.

There is no language construct in C++ which can represent that meaning of s.f. Such a construct would need to store a reference to s as well as the member S::f.

A function pointer can't do that. Function pointers need to be able to be pointer-interconvertible with void*^**. But such an s.f would need to store the member S::f as well as a reference to s itself. So by definition, it'll have to be bigger than a void*.

A member pointer can't do that either. Member pointers explicitly don't carry their this object along with them (that's kind of the point); you must provide them at call-time using the specific member pointer call syntax .* or .->.

Oh, there are ways to encode this within the language: lambdas, std::bind, etc. But there is no language-level construct which has this precise meaning.

Because C++ is asymmetric in this way, where s.i has an encodable meaning but not s.f, C++ makes the unencodable one illegal.

You may ask why such a construct doesn't simply get built. It's not really that important. The language works perfectly fine as is, and due to the complexity of what an s.f would need to be, it's probably best to make you use a lambda (for which admittedly there should be ways to make it shorter to write such things) if that's what you want.

And if you want a naked s.f to be equivalent to S::f (ie: designates the member function), that doesn't really work either. First, S::f doesn't have a type either; the only thing you can do with such a prvalue is convert it to a pointer to a member. Second, a member function pointer doesn't know what object it came from, so in order to use one to call the member, you need to give it s. Therefore, in a call expression, s would have to appear twice. Which is really silly.

^*: there are things you can do to complete objects that you cannot do to subobjects. But those provoke UB because they're not detectable by the compiler, because an int* doesn't say if it comes from a subobject or not. Which is the main point; nobody can tell the difference.

^**: the standard does not require this, but the standard cannot do something which out-right makes such an implementation impossible. Most implementations provide this functionality, and basically any DLL/SO loading code relies on it. Oh, and it would also be completely incompatible with C, which makes it a non-starter.

Answer 2

The stat_result.st_mtime syntax was inherited from C, where it always has a value (more particularly, an lvalue). It is therefore syntactically an expression even in the case of a method call, but it has no value because it is evaluated in concert with its associated call expression.

It is (as you quoted) given the type of the member function so as to satisfy the requirement that a function be called via an expression of the correct type. It would, however, be misleading to define decltype for it since it cannot be a full-expression (as is every unevaluated operand) and common expression SFINAE with decltype would not prevent a hard error from the guarded instantiation.

Note that a non-static member function can be named in an unevaluated operand, but that allows S::f (or just f within the class, although that is arguably rewritten to be (*this).f in a member function), not s.f. That expression has the same type but is itself restricted (to appearing with & to form a pointer to member [function]) for the same reason: if it were to be used otherwise, it would be usable as a normal [function] pointer, which is impossible.