How about a 100% CTFE?

[Gor Gyolchanyan]

> 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 <deadalnix at 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.
>