On Wed, 09 May 2012 13:45:04 -0700, Jacob Carlborg <[email protected]> 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/
