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 castimplicitly 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 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 (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 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 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 castimplicitly 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 castimplicitly converted to double.

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