On Thu, 10 May 2012 12:04:44 -0400, deadalnix <[email protected]> wrote:
Le 10/05/2012 17:54, Steven Schveighoffer a écrit :
On Thu, 10 May 2012 10:47:59 -0400, Andrei Alexandrescu
<[email protected]> wrote:
On 5/10/12 6:17 AM, Steven Schveighoffer wrote:
On Wed, 09 May 2012 23:00:07 -0400, Andrei Alexandrescu
<[email protected]> wrote:
Actually the point here is to still be able to benefit of di
automated
generation while opportunistically marking certain functions as "put
the body in the .di file".
If you aren't going to strip the files, I don't see the point in it.
Inlining.
No, I mean if dmd -H isn't going to strip the files, what is the point
of dmd -H? I can already copy the .d to .di and have inlining/ctfe, or
simply use the .d directly.
At this point, in order to get CTFE to work, you have to keep just about
everything, including private imports. If we want to ensure CTFE works,
dmd -H becomes a glorified cp. If we have some half-assed guess at what
could be CTFE'd (which is growing by the day), then it's likely to not
fit with the goals of the developer running dmd -H.
-Steve
If you can CTFE, you can know what is CTFEable. If it is currently half
assed, then work on it and provide a better tool.
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?
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.
Plus, what isn't CTFEable today may be CTFEable tomorrow.
inlining is one thing, because that's an optimization that has a valid
fallback. CTFE does not.
-Steve
