https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99599
--- Comment #4 from the_gamester28 at msn dot com --- (In reply to Jason Merrill from comment #2) > (In reply to the_gamester28 from comment #0) > > It seems that the template requirements of invoke_tag(bar_tag, int) are > > considered while evaluating line marked "here". Requirements of irrelevant > > overloads should not be considered, as it can potentially lead to falsely > > reporting a cyclic dependency. > > This is as specified by http://wg21.link/cwg2369 > > I think it would be reasonable to allow a compiler to accept the testcase > under a generalization of 13.9.1/9: "If the function selected by overload > resolution (12.4) can be determined without instantiating a class template > definition, it is unspecified whether that instantiation actually takes > place." > > But that does not require a compiler to accept it. > > It might make sense to check non-dependent conversions that don't require > template instantiation, then constraints, then non-dependent conversions > that do require template instantiation. But that's a matter for the > committee; G++ is conforming to the current working paper. Perhaps I was too quick to assert what I expected the implementation details to be. The fooable<T> concept should be satisfied for any (T it) for which invoke_tag(foo_tag{}, it) is unambiguously applicable. The fact that the invoke_tag(bar_tag, T) overload exists should not preclude that. It is not up to me how the compiler comes to that end, but that is the desired outcome. It is still possible to ban recursive constraints, keep the new GCC 11 implementation, and still have this particular code compile with a small alteration in behaviour: The compiler does not immediately bail out as soon as it sees recursion in an overload candidate, but marks that particular candidate as invalid. If there are no applicable overloads (because they are all recursive, or they are invalid for some other reason), then the compiler can reject the code and list all of the reasons why all of the candidates are invalid. In this case, it would mark invoke_tag(bar_tag, int) as not-applicable due to the constraint recursion, and carry on checking the rest of the overloads for applicability, until it is sure that there is one and only one applicable overload: invoke_tag(foo_tag, int).
