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

[Jonathan M Davis]

On 2011-07-20 16:06, Don Clugston 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.

That may be, but many consider CTFE to be a big enough feature that 
disallowing it in the standard library (which would happen if we switched it 
all to .di files) would be unacceptable. So, while there may be a better 
solution which we could implement later, the question of how to handle it now 
remains.

- Jonathan M Davis