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

2474. <cmath> functions unfriendly to integral_constant arguments

Section: 29.7 [c.math] Status: NAD Submitter: Matheus Izvekov Opened: 2015-02-13 Last modified: 2015-12-17

Priority: 4

View all other issues in [c.math].

View all issues with NAD status.

Discussion:

Using numeric wrappers with <cmath> functions is currently troublesome. Code such as: "std::exp2(std::integral_constant<int, 5>{})" will fail to compile because of ambiguity.

Arguments which are implicitly convertible to an arithmetic type should be accepted whenever the latter would be accepted.

David Krauss pointed out that some issue may present itself with numeric libraries which provide <cmath> equivalents in their own namespace which are not more specialized than the ones provided in <cmath>. If the changes proposed are implemented, then cases where the user brings those into scope through ADL might become ambiguous.

It's hard to assess how much breakage this would cause in the wild, and how much work it would take to fix. Should this be determined to be a problem, it's possible to make the new behaviour optional, and disabled by default for all user-defined types.

[2015-10, Kona Saturday afternoon]

STL: This should be NAD, NAD-future and NAD-go-away. Users can already solve this using Walter's call syntax.

VV: I don't personally have this problem, but the proposed resolution seems frightening to me.

VV: There's a related issue, 2294, and also 2192.

STL: 2086 is about user-defined types in <cmath>, fixed in C++14. The PR for 2474 wants to undo the fix.

Link to 2086(i) and NAD.

Proposed resolution:

This wording is relative to N4296.

  1. Change 29.7 [c.math] p11 b2 as indicated:

    -11- Moreover, there shall be additional overloads sufficient to ensure:

    1. […]

    2. Otherwise, if any arithmetic argument corresponding to a double parameter has type double or an integer typea type which is not floating-point, but which is implicitly convertible to double, then all arithmetic arguments corresponding to double parameters are effectively cast to double.

    3. […]