> CTFE must be limited to functions with no side effect, or with side effect > that are known and manageable.
A D front-end can be library-based and completely CTFE-able. This brings a huge set of things you can do with such a front-end. You can create a full-fledged library-based D compiler if necessary. On Mon, Nov 7, 2011 at 5:35 PM, Gor Gyolchanyan <gor.f.gyolchan...@gmail.com> wrote: > Can you show an example of when CTFE modifies the state of the program > and when it's impossible to perform at run-time, provided, that it's a > separate compiler-aware run-time. > >> CTFE must be limited to functions with no side effect, or with side effect >> that are known and manageable. > > Why? There are tons of applications for CTFE other, then initializing > variables. > > On Mon, Nov 7, 2011 at 5:25 PM, deadalnix <deadal...@gmail.com> wrote: >> This doesn't make any sens. >> >> Function can modify the state of the program in a non repeatable way, thus >> compile time function execution isn't possible for thoses. >> >> CTFE must be limited to functions with no side effect, or with side effect >> that are known and manageable. >> >> Le 07/11/2011 14:13, Gor Gyolchanyan a écrit : >>> >>> After reading >>> >>> http://prowiki.org/wiki4d/wiki.cgi?DMDSourceGuide >>> https://github.com/gor-f-gyolchanyan/dmd/blob/master/src/interpret.c >>> >>> I had a thought: >>> Why not compile and run CTFE code in a separate executable, write it's >>> output into a file, read that file and include it's contents into the >>> object file being compiled? >>> This would cover 100% of D in CTFE, including external function calls >>> and classes; >>> String mixins would simply repeat the process of compiling and running >>> an extra temporary executable. >>> >>> This would open up immense opportunities for such things as >>> library-based build systems and tons of unprecedented stuff, that I >>> can't imagine ATM. >> >> >