Every single function in std.math must CTFE. At very least, let's start with pow, log, exp, sin/cos and friends... Curves exist. Populating tables with curve data is a thing that I *constantly* want to do. I usually workaround with a static constructor that pre-computes tables at startup, but that only solves some subset of cases. When I want those tables to interact with other CTFE code, I'm blocked.
I think they already are, but I could be wrong. Did you try forcing the compile time evaluation? I had no problem running the following ``` enum r = pow(2.0, 5); static assert(r == 32.0); static assert(log(E) == 1); enum f = sin(-2.0f); static assert(fabs(f - -0.909297f) < .00001); ``` Those are all altered unittests from std.math, to which I added `enum varName` and `static assert` instead of `assert`
(In reply to Manu from comment #0) > I usually workaround with a static constructor that pre-computes tables at > startup, but that only solves some subset of cases. When I want those tables > to interact with other CTFE code, I'm blocked. Maybe you can replace the static ctor with this idiom https://p0nce.github.io/d-idioms/#Precomputed-tables-at-compile-time-through-CTFE
(In reply to Eduard Staniloiu from comment #2) > Maybe you can replace the static ctor with this idiom > https://p0nce.github.io/d-idioms/#Precomputed-tables-at-compile-time-through- > CTFE That's exactly what he's trying to do. In 2.083.0, the following functions in std.math are still not CTFE-able: nextPow2 truncPow2 asin atan2 expi lround lrint rndtol quantize frexp ilogb scalbn Getting there, though - in 2.081.1, the list was about twice as big.
asin now works at compile time. The rest still fail for the following reasons. nextPow2 -- reinterpret truncPow2 -- reinterpret atan2 -- reinterpret expi -- asm lround -- no avail source lrint -- ditto rndtol -- ditto uantize -- ditto frexp -- reinterpret ilogb -- y.vu[3] is used before initialised scalbn -- asm
Marking this as a duplicate of #17007 since that one is older even though this is the issue with discussion. *** This issue has been marked as a duplicate of issue 17007 ***