*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`

.