Le 10/05/2012 19:51, Steven Schveighoffer a écrit :
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.
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.
