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.
}
``

Reply via email to