-
Notifications
You must be signed in to change notification settings - Fork 226
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
More constexpr for <cmath> and <complex> #1040
Comments
I don't think anyone is using our versions of the functions listed in the paper, but we should probably experiment with this anyway: both for our versions of things listed here (expm1, log1p, erf, tgamma etc) and for other relatively trivial utility functions. Possibly anything that has a simple rational approximation actually. I have two questions for which I confess I've forgotten the answers:
If either are true then we will need some annoying configuration logic and macro-ization. I'm hoping not though... thinking about it, constexpr template functions which are only constexpr depending on certain template arguments would otherwise be impossible? |
I've speculated a bit on this in the past times. I think in C++26 basically most (or all) of the So, since I do not think this applies to those more advanced functions that used to be in TR1. But I guess for POD, it might make sense to get a |
I guess this might be something that finally decides over keeping/not-keeping |
It looks like the following paper has been accepted: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p1383r2.pdf. Since others depend on our special functions in their standard libraries we should probably implement this.
The text was updated successfully, but these errors were encountered: