Proposed resolution:

This wording is relative to N4950.

1. Add a new prototype specification between the current paragraphs 8 and 9 of [complex.member.ops] as indicated:

   [Drafting note: Similar to the proposed wording for LWG 3934, the wording form used below intentionally deviates from the rest of the [complex.member.ops] wording forms, because it seems much simpler and clearer to follow the wording forms used that specify the effects of imag and real functions plus borrowing relevant parts from [complex.members] p2.]

   constexpr complex& operator/=(const T& rhs);
   

   […]

   template<class X> constexpr complex& operator=(const complex<X>& rhs);
   

   -?- Effects: Assigns the value rhs.real() to the real part and the value rhs.imag() to the imaginary part of the complex value *this.

   -?- Returns: *this.

   template<class X> constexpr complex& operator+=(const complex<X>& rhs);
   

   […]

[ 2023-06-17 Approved at June 2023 meeting in Varna. Status changed: Voting → WP. ]

[ 2023-06-01; Reflector poll ]

Set status to Tentatively Ready after eight votes in favour during reflector poll.

The class template complex synopsis in [complex] shows the following member function template:

template<class X> constexpr complex& operator= (const complex<X>&);

but does not specify its semantics. This affects a code example such as the following one:

#include <complex>

int main()
{
  std::complex<double> zd(1, 1);
  std::complex<float> zf(2, 0);
  zd = zf;
}

This problem exists since the 1998 version of the standard (at that time this was declared in subclause [lib.complex]), and even though this looks like a "copy-assignment-like" operation, its effects aren't implied by our general [functions.within.classes] wording (a function template is never considered as copy assignment operator, see [class.copy.assign]).

It should be point out that the refactoring done by P1467R9 had caused some other members to become finally specified that were not specified before, but in addition to LWG 3934's observation about the missing specification of the assignment operator taking a value type as parameter, this is now an additional currently unspecified member, but unaffected by any decision on LWG 3933.