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.
<cmath>
functions unfriendly to integral_constant
argumentsSection: 28.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.
<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.
Proposed resolution:
This wording is relative to N4296.
Change 28.7 [c.math] p11 b2 as indicated:
-11- Moreover, there shall be additional overloads sufficient to ensure:
[…]
Otherwise, if any arithmetic argument corresponding to a
double
parameter has typedouble
oran integer typea type which is not floating-point, but which is implicitly convertible todouble
, then all arithmetic arguments corresponding todouble
parameters are effectively cast todouble
.[…]