Re:What Makes the Zig Programming Language Unique?
by WalterBright on Thursday October 06, 2022 @04:00AM
(#33105691)
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.
Re:What Makes the Zig Programming Language Unique?
by jbb67 on Thursday October 06, 2022 @04:40AM
(#33105983)
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
Great we have many good languages to choose from
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.