CTFE and DI: The Crossroads of D

[deadalnix]

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 agree the module system is way better than having an interface and
> implementation file separate. But when you actually *do* want it to be
> separate (for whatever reason), D pretty much devolves to C.
>

At least it is not worse.