Proposed resolution:

This wording is relative to N4950.

[Drafting Note: Two mutually exclusive options are prepared, depicted below by Option A and Option B, respectively.]

[Drafting note: The wording forms used below intentionally deviate 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. I decided to use "part" instead of "component", which is shorter and more often used in the rest of the specification]

Option A: This assumes that LWG 3933 is considered as NAD and just adds the missing prototype specification assuming that the parameter style of the current working draft is intended.

1. Add a new prototype specification at the very beginning of [complex.member.ops] as indicated:

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

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

   -?- Returns: *this.

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

   […]

Option b: This assumes that LWG 3933 will be resolved as initially presented and just adds the missing prototype specification assuming that the parameter style suggesting two mutually excluded overloads is intended. The wording delta is presented against the proposed wording of LWG 3933.

1. Add a new prototype specification at the very beginning of [complex.member.ops] as indicated:

   constexpr complex& operator=(T rhs) requires floating_point<T>;
   constexpr complex& operator=(const T& rhs) requires (!floating_point<T>);
   

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

   -?- Returns: *this.

   constexpr complex& operator+=(T) requires floating_point<T>;
   constexpr complex& operator+=(const T&) requires (!floating_point<T>);
   

   […]

[ 2023-06-01; Reflector poll ]

Set priority to 3 after reflector poll.

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

constexpr complex& operator= (const T&);

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

#include <complex>
#include <iostream>

int main()
{
  std::complex<double> z(1, 1);
  z = 2;
  std::cout << z << std::endl;
}

This problem exists since the 1998 version of the standard (at that time this was declared in subclause [lib.complex]), but fortunately the three major implementations all behave consistently by assigning the provided value to the real part and nullifying the imaginary part, causing the output (2, 0), which is consistent with the expected behaviour of usual mathematical convention and that of C's built-in complex types. We should specify this.

The lack of this member specification was observed while a proposed wording for LWG 3933 was prepared.