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

Jonathan M Davis jmdavisProg at gmx.com
Fri Jul 22 02:54:48 PDT 2011


On Thursday 21 July 2011 06:54:17 Don Clugston wrote:
> 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.

Ah. Okay. Though that raises the question as to whether druntime should really 
be being shipped only as .di files. Large portions of it would be fine that way 
(particularly the stuff that's just a bunch of C bindings), but some of it 
would likely not.

- Jonathan M Davis


More information about the D-runtime mailing list