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.

### 2846. Undefined phrase "effectively cast"

Section: 28.4.9 [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.9 [cmplx.over], because those conversions can all be done implicitly. This also holds for the `pow` specification 28.4.9 [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.

1. Change 28.4.9 [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 cast implicitly converted (7.3 [conv]) to `complex<long double>`.

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

   > > 3. (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>`:

   > > 1. (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>`.

   > > 2. (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.3) — Otherwise, if either argument has type `complex<float>` or `float`, then both arguments are effectively cast implicitly converted to `complex<float>`.

2. 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:

   > > 1. 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`.

   > > 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 cast implicitly converted to `double`.

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