<div class="gmail_quote">On Wed, Jul 20, 2011 at 4:06 PM, Don Clugston <span dir="ltr"><<a href="mailto:dclugston@googlemail.com">dclugston@googlemail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class="im">On 13 July 2011 23:58, Walter Bright <<a href="mailto:walter@digitalmars.com">walter@digitalmars.com</a>> wrote:<br>
><br>
><br>
> On 7/13/2011 2:21 PM, Jonathan M Davis wrote:<br>
>><br>
>> On 2011-07-13 13:36, Walter Bright wrote:<br>
>>><br>
>>> .di files are used when they are generated from .d files.<br>
>><br>
>> Yes. I get that. But why are .di files generated in the first place?<br>
><br>
> To 1. hide implementation details and 2. speed up compilation.<br>
><br>
>>  Phobos just uses .d files.<br>
><br>
> It'll eventually migrate to .di files.<br>
<br>
</div>That will indeed prevent the use of CTFE.<br>
I'm not sure how to get around that. The basic problem is that CTFE<br>
requires a semantically-analyzed function, in order to be able to run<br>
it. If the source is provided, then you've entirely lost the benefits<br>
of .di files. If it's not provided, you can't do CTFE.<br>
<br>
There are a couple of intermediate options:<br>
Then there's the option of adding the ability to run external<br>
functions from CTFE. A huge amount of work to implement (among other<br>
things, you need to dynamically link to a .obj file, and you have<br>
problems with initialization and gc use).<br>
A deeper problem is cross-compilation: the target CPU may not the same<br>
as the one the compiler is running on. (In fact, that's already the<br>
case with the 64-bit compiler).<br>
Really, you would need to specifically compile a separate version of<br>
each function, for use by CTFE.<br>
If you provide the function in an intermediate form, you add a host of<br>
complications (reminds me a bit of 'export' in C++, maybe not as bad).<br>
<br>
Sounds like a D3 feature to me.<br></blockquote><div><br>I realize I'm not someone that has worked in this area, but how feasible would it be to just ship both d and di files and allow the frontend to only parse the d file only when such a semantic analysis is needed? It would increase the download size, but it seems like it would maintain the compile speeds di gets you without losing CTFE. On the other hand, it could be a lot of frontend work, depending on how much file information the frontend currently maintains.<br>

</div></div><br>