CTFE and DI: The Crossroads of D

[Steven Schveighoffer]

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.

I don't think the situation is "fixable" without deferring to the user.   
Either we defer by using compiler directives exclusively, or we defer by  
simply processing the entire file by stripping all the implementation out,  
then let the author decide what interface functions to put in those  
modules.  Having the compiler decide makes no sense to me.

In most the cases I've seen, dmd -H pretty much includes the whole file  
except comments and whitespace.  But really, all it takes is it including  
one implementation that you *didn't* want public, and you are stuck  
hand-editing.  It's not a very usable situation.

>> As Adam points out in his original post, ensuring CTFE availability may
>> not be (and is likely not) why you are creating a .di file.
>>
>
> You want to create a di file to hide implementation of some  
> functionality to the user of you lib. The better approach is to mark  
> such code as this.

Marking code to specify whether it will be included or not is a valid  
solution.  I would be fine with that too.

But the compiler should stay out of the decision to strip or not based on  
optimization predictions.

> Note that in C/C++ you maintain headers manually. It is already a big  
> improvement.

Let's not kid ourselves -- you have to do the same in D if you want a  
proper interface file.

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.

-Steve