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

[Sean Kelly]

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).