Proposed resolution:

This wording is relative to N4810.

1. Change [cmplx.over], as indicated:

   -2- The additional overloads shall be sufficient to ensure:

   1. (2.1) — If the argument has type long double, then it is effectively castimplicitly converted ([conv]) to complex<long double>.

   2. (2.2) — Otherwise, if the argument has type double or an integer type, then it is effectively castimplicitly converted to complex<double>.

   3. (2.3) — Otherwise, if the argument has type float, then it is effectively castimplicitly converted to complex<float>.

   -3 Function template pow shall have additional overloads sufficient to ensure, for a call with at least one argument of type complex<T>:

   1. (3.1) — If either argument has type complex<long double> or type long double, then both arguments are effectively castimplicitly converted ([conv]) to complex<long double>.

   2. (3.2) — Otherwise, if either argument has type complex<double>, double, or an integer type, then both arguments are effectively castimplicitly converted to complex<double>.

   3. (3.3) — Otherwise, if either argument has type complex<float> or float, then both arguments are effectively castimplicitly converted to complex<float>.

2. Change [cmath.syn], as indicated:

   -2- For each set of overloaded functions within <cmath>, with the exception of abs, there shall be additional overloads sufficient to ensure:

   1. If any argument of arithmetic type corresponding to a double parameter has type long double, then all arguments of arithmetic type ([basic.fundamental]) corresponding to double parameters are effectively castimplicitly converted ([conv]) to long double.

   2. Otherwise, if any argument of arithmetic type corresponding to a double parameter has type double or an integer type, then all arguments of arithmetic type corresponding to double parameters are effectively castimplicitly converted to double.

   3. Otherwise, all arguments of arithmetic type corresponding to double parameters have type float.

[ 2019-03-16; Daniel comments and provides wording ]

I decided to use the form "implicitly converted" and to refer to [conv] for [cmath.syn] and [cmplx.over], because those conversions can all be done implicitly. This also holds for the pow specification [cmplx.over] p3, because the described conversions of complex<T> to complex<U> involve only the need of non-explicit constructors.

[ 2017-01-27 Telecon ]

Priority 3

In [cmplx.over] and [cmath.syn], when talking about "sufficient additional overloads", we use the phrase "effectively cast", but that is not a defined term.

A hostile interpretation could read "reinterpret_cast" here.

Likely we mean "apply floating-point promotions, floating-integral conversions, and floating-point conversions", but that should be spelled out somewhere, e.g. in the library definitions section.

(Source: Editorial issue #1248)