*This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of New status.*

**Section:** 28.4.10 [cmplx.over], 28.7.1 [cmath.syn] **Status:** New
**Submitter:** Jens Maurer **Opened:** 2016-12-15 **Last modified:** 2019-03-18

**Priority: **3

**View all other** issues in [cmplx.over].

**View all issues with** New status.

**Discussion:**

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)

*[2017-01-27 Telecon]*

Priority 3

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

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

**Proposed resolution:**

This wording is relative to N4810.

Change 28.4.10 [cmplx.over], as indicated:

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

(2.1) — If the argument has type

`long double`, then it is~~effectively cast~~implicitly converted (7.3 [conv]) to`complex<long double>`.(2.2) — Otherwise, if the argument has type

`double`or an integer type, then it is~~effectively cast~~implicitly converted to`complex<double>`.(2.3) — Otherwise, if the argument has type

`float`, then it is~~effectively cast~~implicitly 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>`:(3.1) — If either argument has type

`complex<long double>`or type`long double`, then both arguments are~~effectively cast~~implicitly converted (7.3 [conv]) to`complex<long double>`.(3.2) — Otherwise, if either argument has type

`complex<double>`,`double`, or an integer type, then both arguments are~~effectively cast~~implicitly converted to`complex<double>`.(3.3) — Otherwise, if either argument has type

`complex<float>`or`float`, then both arguments are~~effectively cast~~implicitly converted to`complex<float>`.

Change 28.7.1 [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:If any argument of arithmetic type corresponding to a

`double`parameter has type`long double`, then all arguments of arithmetic type (6.8.2 [basic.fundamental]) corresponding to`double`parameters are~~effectively cast~~implicitly converted (7.3 [conv]) to`long double`.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 cast~~implicitly converted to`double`.Otherwise, all arguments of arithmetic type corresponding to

`double`parameters have type`float`.