https://gcc.gnu.org/bugzilla/show_bug.cgi?id=127627
--- Comment #7 from songb432 at gmail dot com --- (In reply to Jonathan Wakely from comment #2) > It isn't shown because the more constrained one replaces it. There is only > one copy constructor, decided by evaluating the constraints. The > unconstrained one is not an "eligible special member function" in the > terminology of the standard. (In reply to Jason Merrill from comment #5) > Hmm, GCC assumes that non-eligible special member functions could never be > chosen by overload resolution, but that is not the case here due to > difference in "explicit". And [over] doesn't consider "eligible", so it > looks like GCC is wrong. > > P0848 doesn't seem to consider differences in explicit, perhaps it should be > included in [class.special] "kind" so that GCC's assumption is valid. I'm surprised when seeing that the special member function is really special in GCC. This makes me doubt if `explicit`ness matters in overload resolution. :[ https://godbolt.org/z/zszfshv3P `` template <class T> struct X { X() = default; X(const X&) { throw; } operator int() const { throw; } private: explicit X(const X&) requires (T::value) = default; explicit operator int() const requires (T::value) { return 37; } }; struct S { static constexpr bool value = true; }; static_assert(__is_trivially_copyable(X<S>)); int main() { const X<S> x; { X<S> x2 = x; // Clang compiles. GCC doesn't. } { X<S> x2(x); // Both don't compile. } int i = x; // Both compile. (int) x; // Both don't compile. } ``
