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.