> Well except that module can modify a and not be in the tree. A single compilation includes only two parts: compiling D source code and linking in object files or static libraries. object files and static libraries are by no means involved in compile-time activity, which leaves us with with compiling D source code. A single compilation of D source code can be viewed as a list of import trees, originating from the enlisted modules to be compiled. After eliminating duplicates we have a list of small trees, which can be rooted together to form a single tree, which in turn can be processed as described above. Optionally, in order to allow separate compilations, a cache can be maintained to hold the results of previous compile-time computations to be used in the next ones inside a "project" (to be defined).
> If you have hard time to figure out what the problems are, it is unlikely > that you come up with a satisfying solution, except by being lucky. When i say, i don't see problems, that means, that you didn't present me a problem, which i could not resolve. You point to a problem, i resolve it and vice verse until one of us fails. This is called a discussion. On Tue, Nov 8, 2011 at 4:56 PM, deadalnix <deadal...@gmail.com> wrote: > Le 07/11/2011 17:00, Gor Gyolchanyan a écrit : >>> >>> Well and somefunction ? It does modify teh value of a too. Is it executed >>> before ? after ? What is the value at the end of all that ? >> >> Obviously it will be incremented first. >> The order is dependent of the rules by which the conditions are >> evaluated at compile-time. For example, the compiler will build a >> depth-first list of the import tree and evaluate code sequentially in >> each module. As i already said, it works just like at run-time. >> Is it so hard to imagine taking the compile-time code, run it during >> compilation separately with the exact same rules as it would during >> compilation? >> > > Well except that module can modify a and not be in the tree. > >>> Well, if you don't see any problem, you should probably just stop trying >>> to provide a solution. >> >> Ok, this is just ridiculous. Are you serious about this question or >> are you trolling to say the least? In either way, I don't see any >> problem in _having mutable compile-time values_. >> > > I'm not trolling, I'm dead serious ! If you have hard time to figure out > what the problems are, it is unlikely that you come up with a satisfying > solution, except by being lucky. >