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

[Jonathan M Davis]

On Saturday 16 July 2011 05:01:53 Sean Kelly wrote:
> On Jul 13, 2011, at 4:01 PM, Jonathan M Davis wrote:
> > On 2011-07-13 15:41, Walter Bright wrote:
> >> On 7/13/2011 3:19 PM, Jonathan M Davis wrote:
> >>> Given its heavy use of templates, I'm not sure how much that'll buy
> >>> us in terms of compilation speed, and since it's all open source, I
> >>> don't know why it would matter about hiding implementation details.
> >> 
> >> Consider the garbage collector. Should every compilation have to
> >> recompile that, too?
> > 
> > Since it doesn't take very long to compile, I really don't care much
> > personally, and I think that it's just simpler to only deal with .d
> > files. However, I'm not against the use of .di files if it speeds up
> > compilation and doesn't have any major drawbacks. My primary concern at
> > the moment (and why I brought it up in the first place) is that it
> > seems to be affecting CTFE. For instance, this program
> > 
> > ====
> > import std.stdio;
> > import std.string;
> > 
> > enum a = strip(" hello world");
> > 
> > void main() {}
> > ====
> > 
> > currently fails to compile, giving these errors:
> > 
> > ====
> > /home/jmdavis/dmd2/linux/bin/../../src/phobos/std/string.d(1468): Error:
> > _aApplycd2 cannot be interpreted at compile time, because it has no
> > available source code
> 
> This function is in src/rt, which isn't publicly visible code (much like the
> GC).  Is there a similar example involving a module in core.*?

There may be, but I'd have to play around to find one. I only know about the 
one example, because it was brought up on the newsgroup. But regardless of 
whether there's another example, the fact that that one doesn't work is 
definitely a problem.

- Jonathan M Davis