CTFE and DI: The Crossroads of D

[Steven Schveighoffer]

On Wed, 09 May 2012 23:00:07 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

> On 5/9/12 3:14 PM, Steven Schveighoffer wrote:
>> On Wed, 09 May 2012 15:57:46 -0400, Adam D. Ruppe
>> <destructionator at gmail.com> wrote:
>>
>>> The real WTF is we use .di files for druntime in the
>>> first place. It is performance sensitive and open source.
>>>
>>> We should be using the actual sources for inlining, ctfe,
>>> etc. anyway.
>>>
>>> Let's not torpedo the .di patch's value for just phobos.
>>
>> I agree (although not generating .di files does not fix all the problems
>> of inlining and ctfe -- there are many stubbed functions even in the .d
>> files).
>>
>> In my opinion, .di generation should by default generate fully-stripped
>> code except for templates. If you want functions to be CTFE-able, don't
>> use auto-generated .di files to import them.
>>
>> -Steve
>
> Actually the point here is to still be able to benefit of di automated  
> generation while opportunistically marking certain functions as "put the  
> body in the .di file".

If you aren't going to strip the files, I don't see the point in it.

If you want a 'half stripped' .di file, use the plethora of shell commands  
to build it.

The point is, dmd -H does the wrong thing, no matter which way you look at  
it.  We have a tool to make a .di file with function bodies in it, it's  
called cp.  dmd -H should do the thing that the shell cannot, let me worry  
about it's granularity (i.e. I'll decide on a module basis which functions  
should be stripped).

-Steve