CTFE and DI: The Crossroads of D

[Adam Wilson]

On Wed, 09 May 2012 13:45:04 -0700, Jacob Carlborg <doob at me.com> wrote:

> On 2012-05-09 21:27, Adam Wilson wrote:
>> Hello Everyone,
>>
>> I am afraid that we as a community have reached an inflection point. The
>> crossroads of CTFE and DI.
>>
>> I recently completed my work on a patch for the DI generation system. In
>> the process I solicited the feedback of the community about what should
>> and should not be in a DI file. The most agreed up point was that all
>> functions that can loose their implementations should. In the
>> communities opinion that means only auto-functions and
>> template-functions should retain their implementations.
>>
>> The problem is thus: CTFE requires that any function that it could
>> possibly evaluated by CTFE, must retain it's implementation.
>> Unfortunately, there is simply no way for the DI generation system to
>> know which functions are capable of being called by CTFE and which ones
>> actually are.
>>
>> This limitation is due to the fact that DI generation must be run before
>> Semantic Analysis because said analysis may perform significant rewrites
>> of the AST. There is even a large (for DMD) comment in the main function
>> of DMD explaining that DI generation should not be moved from where it
>> is due to the inconsistencies that could arise.
>
> In the long run the compiler needs to run some form of (limited)  
> semantic analysis to be able resolve inferred types.
>

It certainly does, but that's a LOT more work than we have time for at the  
moment.

>> The patch I created currently fails in the autotester because the
>> template function dur() in the druntime is called via CTFE from Phobos.
>> Per the community agreed upon DI rules, the function implementation of
>> the Duration constructor that is called by the dur() function is
>> stripped away and CTFE fails.
>
> A workaround to force a function/type to appear in DI files with their  
> implementation is to make it into a template.
>
> void foo () () {}
>
> Will always show up in the DI files.
>

If this example works on constructors, I have no problem making the  
changes and opening a pull on the drt assuming it doesn't semantically  
alter the function.

In the long run I think an @implementation attribute would be nice because  
I could use that to direct the DI generator to include the whole  
implementation in the DI file, and this would be an acceptable solution  
for business.

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/