Is there a reason we cannot name a non-static member function in an unevaluated context?

Question

When reading [expr.prim.id], one will see that

An id-expression that denotes a non-static data member or non-static member function of a class can o

Answer 1

Is there some ambiguity I'm missing?

The fact there's a whole lot of type information that is added as part of that member function declaration.

While func may certainly be used to declare that member, the story doesn't end here. Once the member is declared, it's type is completed. That involves adding a couple of other things, like cv-qualifers and ref-qualifiers. In the case of foo, all the default implicit ones are determined, and they become part of bar::foo's type. As specified by [dcl.fct]/8:

The return type, the parameter-type-list, the ref-qualifier, the cv-qualifier-seq, and the exception specification, but not the default arguments, are part of the function type.

There's no way to specify them explicitly in the above declaration of foo (though they may be added to func), but they may be added in general:

class bar {
  int foo() const volatile &&;
};

They are part of the function type, and decltype(bar::foo) should address them if they appear (and if I gather correctly, even if they don't).

Where does the const volatile && go when we attempt to evaluate decltype(bar::foo)?

• Should it be ignored? That can be done. But losing type information is rarely a good thing.
• Should we retain it, and the type decltype evaluates to be a pointer to a member function, instead?
  That too would work, but now it's different from how data members would behave when named in an unevaluated context. We introduce a discrepancy.
• Should it be retained, and the type resolved to something else? Perhaps something like int(foo const volatile&&) or int() const volatile && (another form of function type)? That breaks the symmetry one would expect to have, and is again a discrepancy to data members.

There is no easy or obvious way in which allowing it would always work well. So rather than complicate matters for a feature that would see limited use, it's better to regard it as ill-formed.