[Bug c++/90848] New: A recurring bug: Overeager application of conversion to function pointer during overload resolution of call to function object

[zhonghao at pku dot org.cn]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90848

            Bug ID: 90848
           Summary: A recurring bug: Overeager application of conversion
                    to function pointer during overload resolution of call
                    to function object
           Product: gcc
           Version: 10.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: zhonghao at pku dot org.cn
  Target Milestone: ---

A bug report (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71117) complains
that GCC accepts the code:

template<typename T> using id = T;
struct F {
  template<typename T> operator id<T(*)(T)>();
} f;
int n = f(0);


Clang, EDG, MSVC reject it. Some comments are as follows:

"Per [over.call.object]/2, I think GCC is wrong per the current language
wording. A conversion function template does not qualify as a "non-explicit
conversion function declared in [F or base class thereof]" (because it is not a
conversion function), and nor does a specialization of one (because it is not
itself declared in F).

I also don't see any way the current wording would take us to
[temp.deduct.conv] for this case, nor how that wording would apply (since we
don't have a function type that's required as the result of the conversion).
Perhaps GCC is following the rules of [temp.deduct.call] in this case, treating
the (pointee type of the) result type of the conversion function as if it were
the function type of the callee?

In the abstract, GCC's approach to this situation seems superior -- it's able
to use a conversion to function pointer in many cases where other compilers
can't -- but I'm a little hesitant to suggest we adopt that approach since it
breaks examples like yours."

I tried gcc 10.0.0. It still accepts it, although the above bug is marked as
fixed.