On Thu, 10 May 2012 13:27:23 -0400, deadalnix <[email protected]> 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
