I agree! But the compile-time interpreter isn't really "full". For example, you can't do arbitrary I/O in a compile-time expression (by design). Non-portable casts and inline ASM are other exceptions. See [1] for the full story.
> Compile time IO doesn't make much sense either.
As it turns out (IME) referencing arbitrary data (such as a database schema queried from a 'live' database) is actually of quite limited value.
Where I actually agree that it makes sense is the 'read-a-checked-in-file-and-generate-code-at-compile-time-from-that'. Otherwise, you're mostly just looking at a lot of pain compared to just generating code (that you might check in).
Actually you can do this on CTFE on D, doing an import of a file and dumping it to an enum. The only big pitfall of this, is that enforces to read the whole file by the compiler.
An important difference is that the compiler doesn't know it's using that file ahead of time, which could have some unforeseen consequences, but I don't see anything immediately worrying about that fact since the compiler didn't know about the source either at it's own compile time.
It can be done with:
void[] ctData = import("file.xml");
Considering what we've known about the typical behavior of production programs for decades, why isn't there also an "Initialization Time" in addition to Compile Time and "runtime." (Steady State Time?)
I think it has a bad rap because it's often used to initialize some kind of global state, with all the cons global state brings.
So then what if the language didn't have global state, or only had immutable global state?