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.
(In reply to zhonghao from comment #0) > A bug report (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71117) complains > that GCC accepts the code: No, that's not what the bug report was about. The bug was that the first piece of code was not accepted, and that bug was fixed, and is still fixed. The behaviour for the code you showed didn't change, so there is no "recurring bug". As Richard Smith said in the other bug, GCC's behaviour seems superior. I believe this is the subject of https://wg21.link/cwg2189 so I'm suspending this.