On Saturday, 30 April 2022 at 07:08:48 UTC, Ola Fosheim Grøstad wrote:
> I understand why both D and C++ users make a fuzz about CTFE, it gives them a feeling of being able to extend the type system or language in a way they are used to. However they are still at wn disadvantage to more powerful languages that allow construction of new types at runtime and do CTFE as an optimization.
No, we're not at a disadvantage. If CTFE was just an optimisation, it'd mean we could not use it to compute values that have to be compile-time by definition. Example:
//CTFE-able function
@safe pure size_t neededSize(size_t a, size_t b)
{ //Whatever...
}
struct SomeTemplateStruct(T)
{ //This wouldn't be possible without CTFE built in to semantics
ubyte[neededSize(T.sizeof, 4)] anArray;
//Neither would this
static if(neededSize(T.sizeof, 8))
{ //...
}
}
> Reason 1: compilation performance.
Reason 2: poor debugging tooling.
I'd say you don't have a proper CTFE solution until you can set breakpoints in all functions and see what goes on.
You can still execute the CTFE-able functions at runtime when these are what you prefer.
And nothing prevents the compiler backend from optimising the calculations to compile time even when they are semantically runtime, which I understand is what you're advocating.
> One possibility is to reuse WASM infrastructure by compiling CTFE functions to WASM and use source maps for debugging.
What do you think?
Complex and not needed, for reasons above.