On Thursday, 10 May 2012 at 17:37:59 UTC, Adam Wilson wrote:
On Thu, 10 May 2012 09:56:06 -0700, Steven Schveighoffer
<[email protected]> wrote:
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
Exactly this. I am currently in the process of changing the
DRuntime makefiles such that some of the files are not
processed as DI's. This allows Phobos CTFE dependencies on the
DRT to remain valid while still allowing DI's to be generated
for parts where they matter, with the goal of making both a
shared and static library build of the DRT. The tool I am using
to accomplish this feat? cp. It works, it delivers exactly what
we need and it's *is not* a broken operation like the current
DI generation.
Like Steve said, most people generating DI files are not really
worried about CTFE working, in fact they almost undoubtedly
*know* that they are breaking CTFE, yet they choose to do it
anyways. They have their reasons, and frankly, it doesn't
concern us as compiler writers if those reasons don't line up
with our personal moral world-view. Our job is to provide a
tool that DOES WHAT PEOPLE EXPECT. Otherwise they will move on
to one that does. If people expected DI generation to be
glorified (and not broken) copy operation, they would (and do)
use cp.
How about:
dmd -H mySource.d --keepImplementation MyClass.fooMethod
?
It should be good enough for makefiles as in the case of
core.time/dur, but get's a bit hairy with overloads (append "[0]"
to select specific ones?). Maybe it requires semantic
information though.
