CTFE and DI: The Crossroads of D

[deadalnix]

Le 10/05/2012 20:25, deadalnix a écrit :
> Le 10/05/2012 19:51, Steven Schveighoffer a écrit :
>> On Thu, 10 May 2012 13:27:23 -0400, deadalnix <deadalnix at gmail.com>
>> wrote:
>>
>>> Le 10/05/2012 18:56, Steven Schveighoffer a écrit :
>>>> There is already a better tool -- cp. I ask again, what is the benefit
>>>> of .di generation if it is mostly a glorified (faulty?) copy operation?
>>>>
>>>
>>> Please stop with that cp argument, this is complete bullshit.
>>
>> Not complete. Maybe it's somewhat of an exaggeration ;)
>>
>> But really, I look at the current situation that started this thread.
>> The intention of .di header generation retaining implementation is to
>> allow for inlining, not making CTFE available. Yet a side effect is that
>> sometimes CTFE *is* available.
>>
>> Well, let's say something becomes uninlinable, and now dmd decides to
>> remove its implementation. But another piece of code is already
>> depending on that source to be available for CTFE! Now you have broken
>> code inadvertently, and the only way to fix it is to hand-edit the .di
>> file.
>>
>
> The di generator can remove code that isn't CTFEable (at least can be
> proven to not be CTFEable). It is the case in your example.
>
>> But the compiler should stay out of the decision to strip or not based
>> on optimization predictions.
>>
>
> The compiler should provide something by default. It is up to the user
> to mark the code accordingly.
>

I wanted to add that the default behavior should break anything. So it 
have to be conservative with CTFEable code unless told otherwise by some 
attribute.