How about a 100% CTFE?

[deadalnix]

module a;

int a = 0;

int somefunction() {
	a++;
	return a;
}

static if(somefunction() == 1) {
	// Some code
}

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 ?

exemple :

module b;

import a;

int someotherfunction() {
	a--;
	return a;
}

static if(someotherfunction() < 10) {
	// Some code
	
	import std.stdio;

	immutable int b = somefunction();
         static this() {
		writeln(b);
	}
}

What the hell this program is supposed to print at run time ?

Le 07/11/2011 14:35, Gor Gyolchanyan a écrit :
> 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<deadalnix at 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.
>>
>>