CTFE and DI: The Crossroads of D

[Jacob Carlborg]

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.

> 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.

-- 
/Jacob Carlborg