How about a 100% CTFE?

[Ary Manzana]

On 11/8/11 10:44 AM, deadalnix wrote:
> Le 08/11/2011 14:31, Gor Gyolchanyan a écrit :
>>> 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).
>>
>
> module a;
>
> int a = 0;
>
> -------------------
>
> module b;
>
> import a;
>
> int somefunction() {
> return ++a;
> }
>
> static assert(somefunction() = 1);
>
> -------------------
>
> module c;
>
> import a;
>
> int somefunction() {
> return ++a;
> }
>
> static assert(somefunction() = 1);

There answer here is: who cares?

Is your point to prove that you can make some code that is useless? Why 
not make something useful with CTFE?

It's sad to see people come here proposing great ideas (I think CTFE 
beyond what D is capable is great, and I'm implementing that in my own 
language) and other people come with nonsense useless examples to ask 
"What happens here?"

Use the tool to make magic, not to show how you can get undefined 
behaviour...