<div class="gmail_quote">On Thu, Jul 14, 2011 at 4:01 AM, Steve Schveighoffer <span dir="ltr"><<a href="mailto:schveiguy@yahoo.com">schveiguy@yahoo.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div><div style="color:#000;background-color:#fff;font-family:arial, helvetica, sans-serif;font-size:12pt"><div><span>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.<br>

</span></div><div><br><span></span></div><div><span>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).</span></div><div><br><span></span></div><div><span>-Steve<br></span></div></div></div></blockquote><div><br></div><div>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.</div>

<div>On the other hand, it would provide a strong guarantee about a D feature that's somewhat nebulous right now.</div><div>Thoughts?</div></div>