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

[Andrew Wiley]

On Thu, Jul 14, 2011 at 4:01 AM, Steve Schveighoffer <schveiguy at yahoo.com>wrote:

> Right.  I would think the most important reason to use .di files is to hide
> private imports.  The GC is a good example, you don't want to import the GC
> implementation when importing core.memory.  But in fact, core.memory doesn't
> import anything from rt, it links to the GC implementation via extern(C)
> functions, so the implementation of core.memory is not a good example.
>
> I think to a point, using .di files has merit.  To be certain, anything
> that imports anything from rt should be hidden (I'm not sure if there are
> any cases of that).  But we should consider the cost of disabling CTFE on
> druntime functions, especially those in core that really aren't managing the
> actual runtime of the compiler, but are just tools used by both druntime and
> phobos (core.time and core.math come to mind).
>
> -Steve
>

It seems to me that a way to fix all this and guarantee CTFE-ability (which
seems to be the end goal) would be to add some sort of modifier or
annotation to designate that a function is CTFE-able. This could be verified
by the compiler at build-time and used as a flag to emit full function
source when generating a di file. Things get more complicated because it
would have to be transitive, so it wouldn't be a simple addition, and might
be heavier than what we're looking for.
On the other hand, it would provide a strong guarantee about a D feature
that's somewhat nebulous right now.
Thoughts?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/d-runtime/attachments/20110714/336c91b2/attachment.html>