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

[Jonathan M Davis]

On Sunday 24 July 2011 22:02:08 Sean Kelly wrote:
> On Jul 22, 2011, at 2:53 AM, Jonathan M Davis wrote:
> > 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.
> 
> I disagree, but mostly because this is an issue of how the runtime is
> designed than whether .d or .di files are generated.  Even if druntime were
> shipped with all .d files the issue would remain because the rt/* modules
> are imported by user code.  This is actually kind of an interesting issue
> because the fix would be a fundamentally different approach to the runtime
> design, and one that may be a much better design (because the resulting
> code could be optimized much more heavily) but may also turn out to be a
> bear to deal with.
> 
> In essence, the fix would be to have every function that is called by
> compiler-generated code be exposed by object.di.  I suspect that this would
> expose a good part of the now hidden compiler runtime code to the user,
> which not every compiler writer may like doing.  Which raises an
> interesting point.  Should CTFE support be consistent across compilers? 
> I'd be inclined to say so, but this appears to have interesting
> implications in terms of how code generation occurs regarding language
> features (array operations in particular).

>From the user's perspective, the fact that you can't iterate over a string 
with CTFE is a big problem ( 
http://d.puremagic.com/issues/show_bug.cgi?id=3512 ) regardless of what the 
reasons for it might be. It's hugely limiting.

Personally, I don't understand all of the issues involved, so I have no idea 
what the correct fix is. But most programmers are going to want it to "just 
work," and right now it doesn't. It may be that the problem is big enough that 
it's going to take a while to come up with an appropriate fix, but I don't 
think that it's really acceptable to disallow iteration over strings in CTFE 
unless it just really can't be done in any sane way. It's just too limiting 
(especially when you consider stuff like string mixins).

And yes, I think that CTFE should be consistent across compilers. It's going 
to be a problem if it isn't. There seem to be a number of people who rely on 
CTFE quite a bit on their code, and it's supposed to be one of D's selling 
points, so it needs to be appropriately portable. That could be problematic 
depending on what all of the implementation issues are, but it's also going to 
be problematic if CTFE doesn't work the same way across compilers.

So, obviously, there are some issues which need to be sorted out here, and 
that may take time, but the situation with regards to CTFE and strings 
definitely needs to be improved.

- Jonathan M Davis