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

Don Clugston dclugston at googlemail.com
Wed Jul 20 16:06:05 PDT 2011

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.

More information about the D-runtime mailing list