I find that the hard part with designing macros and other metaprogramming constructs that run at compile time is not adding POWER - that part is easy, but to make it readable and easy to understand.

If a reader of the code needs to stop to work out the code then that is a weakness, not a strength - as such a pause in code reading affects everything from refactoring to spotting bugs.

In Zig, compile time code looks like runtime code and you cannot easily know which is which without looking up the definition of the variables.

Turning some statements into compile time, like for, requires ”inline” while some, like if, always folds at compile time if it is constant resolved, skipping even semantic checking of the ”dead” branch.

Grasping this at a glance is very challenging.

There is also the issue of generating types - and not just values - at compile time.

This means that a tool refactoring a compile time defined struct member must know how that struct member was created - which may be through arbitrary code execution.

All of this, and including ”build.zig”- the build tool describing how to compile a project using code invocations, makes it extremely challenging for an IDE to reason about code and provide meaningful analysis and refactoring tools.

Which also in the end may affect overall code quality.

So it’s a trade-off. For a contrast, look at C3 which has a comparable amount of compile time but tries to be IDE friendly.