On Thu, 10 May 2012 11:25:11 -0700, deadalnix <[email protected]> wrote:
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.
False. No semantic analysis has been performed therefore DMD has no idea
what is and is not CTFEable.
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.
This is pretty much what we are advocating with the attribute solution.
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.
Does not D strive to be better than C++, much less C? I think we can do
better with DI's too.
--
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/
