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

Don Clugston dclugston at googlemail.com
Wed Jul 20 21:54:17 PDT 2011


On 21 July 2011 01:55, Jonathan M Davis <jmdavisProg at gmx.com> wrote:
> 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.

I mean shipping Phobos only as .di files sounds like a D3 feature for
this reason.


More information about the D-runtime mailing list