The idea behind compile time evaluation is that expressions which are not syntactically constant expressions can also be evaluated at compile time. A function definition can be marked as being available at compile time. When the body of a function f(x) refers to x, that is not a constant expression syntactically. However, an expression like f(3) can be considered a constant expression, since it passes a constant to function that has been marked as a compile-time function.
D uses `enum` to specify a manifest constant, which evaluates at compile time:
int i = f(3); // evaluate at run time
enum i = f(3); // evaluate at compile time
Note that it's not the function that is specified as being run at compile time, it is the use of the function that determines it. There is no difference between compile time functions and runtime functions. The use that triggers a function to be evaluated at compile time is when the function call is in a const-expression.
Obviously, there is no difference between run-time functions that are qualified for compile-time execution, and compile-time functions.
Then, suppose we have all these requirements
- We want a separate compilation model where the code which is calling f(3) at either compile or run time knows nothing about how f is defined, only how it's declared.
- We want not to include the compiled image of f in the target program, if if is only called at compile time, only if at least one call to it somewhere in the program is staged to run-time.
- We want to make sure that if f is called at compile time, nobody can change its definition to accidentally call for run-time semantics like toggle_gpio(FRONT_LED_2).
and that's how we probably arrive at a declarative mechanism like constexpr that goes on the function, rather than trying to orchestrate thing remotely/indirectly by placing a call to the function into a compile-time context.
D guarantees that a function annotated with `pure` will also work at compile time. But compile time does allow calling some impure functions, as long as the path taken through the function's body is pure. This greatly expands the palette of functions able to be executed at compile time.
Not including functions never called for runtime execution in the runtime is a normal compiler optimization. No user input is necessary.
If the function's semantics change so it is no longer runnable at compile time, the compiler will let you know when you try it. If you want to force the detection, just call it at compile time with dummy declaration.
> that's how we probably arrive at a declarative mechanism like constexpr that goes on the function, rather than trying to orchestrate thing remotely/indirectly by placing a call to the function into a compile-time context.
This issue is raised now and then, and in 16 years of CTFE in D it has never ever been reported as causing an actual problem.
I really like zig and think it is potentially a great language. I also used D a little in the past too, but somehow drifted away but some of the comments here make me want to revisit it
