Why it doesn't compile in D 2.0?

[Lutger]

On 01/16/2010 04:18 PM, aarti_pl wrote:
> W dniu 2010-01-16 15:30, Lutger pisze:
>>
>> Perhaps this is or should be a bug. You can override dup to work in ctfe:
>>
>> char[] dup(string str)
>> {
>> return str.dup;
>> }
>>
>> class Test {
>> string t1 = "test"; //Ok!
>> char[] t2 = "test".dup; //Compile error
>> char[] t3 = "test".dup(); //Ok!
>> }
>>
>> The spec even mentions it under ctfe:
>>
>> 6. as a special case, the following properties can be executed at
>> compile time:
>> ..dup
>> ..length
>> ..keys
>> ..values
>>
>> http://www.digitalmars.com/d/2.0/function.html
>>
>
> Thanks! I will use function dup() as a workaround for now, and will put
> bug to bugzilla.
>
> I still wonder what has CTFE to do with this case. Do you know?
>
> I am asking because it's not possible in general case to initialize all
> variables in classes/structs and in global namespace.
> E.g. I had to use:
>
> Serializer!(TextArchive) serializer;
> static this() {
> serializer = new typeof(serializer);
> }
>
> to initialize serializer. I am wondering if with better CTFE we could
> get it working?
>
> BR
> Marcin Kuszczak
> (aarti_pl)

ctfe is basically a user defined extension of constant folding, which is 
also mentioned in the spec that way. So to use it for more complex 
initialization makes sense, but this is constrained to compile time. 
 From the example of the serializer, all we know is that it allocates 
memory. Array dup-ing also allocates memory however, so theoretically I 
see no immediate reason why it would not (eventually) be possible to use 
ctfe in that case. But it may be difficult to prove statically by the 
compiler that it is indeed safe to do so.