How about a 100% CTFE?

[Gor Gyolchanyan]

> 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, 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_.

On Mon, Nov 7, 2011 at 7:49 PM, deadalnix <deadalnix at gmail.com> wrote:
> Le 07/11/2011 15:30, Gor Gyolchanyan a écrit :
>>>
>>> now what is the value of a ? At run time ? At compile ime ? If some other
>>> CTFE uses a ? If a CTFE from another module uses a or worse, update it ?
>>
>> Run-time: Whatever _a_ ends up with by the time CTFE is done. There's
>> a very handy _COUNTER_ macro in Visual C++ compiler, that uses this
>> very feature internally.
>> Compile-time: The same, that it would have if run in run-time:
>> sequentially updated after the compile-time value (naturally).
>>
>>> What the hell this program is supposed to print at run time ?
>>
>> Assuming that somefunction was never called, this would print -1.
>> That's because _a_ has a resulting compile-time value if -1 due to
>> having decremented once by the someotherfunction() inside the static
>> if and b is being initialized by -1.
>>
>
> 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 ?
>
>> I don't see any problems in either of these cases.
>> The whole point of a mutable compile-time value is to have essentially
>> two values, one of which is computed at compile-time and the other,
>> which is statically initialized by the first one.
>>
>
> Well, if you don't see any problem, you should probably just stop trying to
> provide a solution.
>