Any struct containing a comptime pointer can only be used in a pure comptime context. You cannot intermix it with runtime code. That’s why I had to replace the call to std.debug.print() with @compileLog(). Even then it’s necessary to keep it inside the comptime block.
In order to anything useful–that is, have this comptime data structure affect your runtime code in some way–you’d have to generate a entirely separate tree that mirrors this one but which has no comptime pointers.
thanks, @chung-leong … i know you’ve posted on similar idioms with comptime…
this is a key point, in that many of the comptime var examples would “freeze” the results into some runtime variable… i’ve seen initializers implemented as comptime blocks, for instance…
i’m thinking out loud here, but perhaps there is a way to have the “comptime-only” state declared as an inner-struct within my ModX… taking this one step further, imagine if there were a finalizeComptime defined by each ModX that would indicate that the receiving struct should “capture” any comptime state such that it can truly be usable at runtime…
A way to freeze a comptime variable would certainly be very useful given the restrictions in place currently. I don’t know if these will be there forever though. Once incremental compilation has been implemented, I think we can start thinking about restoring the sort of comptime capability that we had with 0.11.0.