[D-runtime] Why does druntime us .di files instead of .d?

[Andrew Wiley]

On Wed, Jul 20, 2011 at 4:06 PM, Don Clugston <dclugston at googlemail.com>wrote:

> On 13 July 2011 23:58, Walter Bright <walter at digitalmars.com> wrote:
> >
> >
> > On 7/13/2011 2:21 PM, Jonathan M Davis wrote:
> >>
> >> On 2011-07-13 13:36, Walter Bright wrote:
> >>>
> >>> .di files are used when they are generated from .d files.
> >>
> >> Yes. I get that. But why are .di files generated in the first place?
> >
> > To 1. hide implementation details and 2. speed up compilation.
> >
> >>  Phobos just uses .d files.
> >
> > It'll eventually migrate to .di files.
>
> That will indeed prevent the use of CTFE.
> I'm not sure how to get around that. The basic problem is that CTFE
> requires a semantically-analyzed function, in order to be able to run
> it. If the source is provided, then you've entirely lost the benefits
> of .di files. If it's not provided, you can't do CTFE.
>
> There are a couple of intermediate options:
> Then there's the option of adding the ability to run external
> functions from CTFE. A huge amount of work to implement (among other
> things, you need to dynamically link to a .obj file, and you have
> problems with initialization and gc use).
> A deeper problem is cross-compilation: the target CPU may not the same
> as the one the compiler is running on. (In fact, that's already the
> case with the 64-bit compiler).
> Really, you would need to specifically compile a separate version of
> each function, for use by CTFE.
> If you provide the function in an intermediate form, you add a host of
> complications (reminds me a bit of 'export' in C++, maybe not as bad).
>
> Sounds like a D3 feature to me.
>

I realize I'm not someone that has worked in this area, but how feasible
would it be to just ship both d and di files and allow the frontend to only
parse the d file only when such a semantic analysis is needed? It would
increase the download size, but it seems like it would maintain the compile
speeds di gets you without losing CTFE. On the other hand, it could be a lot
of frontend work, depending on how much file information the frontend
currently maintains.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/d-runtime/attachments/20110720/0ff1bb0b/attachment.html>