Battle-plan for CTFE
    David Nadlinger via Digitalmars-d-announce 
    digitalmars-d-announce at puremagic.com
       
    Mon May  9 11:19:53 PDT 2016
    
    
  
Hi Stefan,
On Monday, 9 May 2016 at 16:57:39 UTC, Stefan Koch wrote:
> My Plan is as follows.
I think you guys talked about it at the conference, but be sure 
to coordinate with Timon Gehr. You'll want to steal all the best 
ideas from the various implementations anyway. ;)
> Do Dataflow analysis on the code that is to be ctfe'd so we can 
> tell beforehand if we need to store state in the ctfe stack or 
> not.
>
> Or baring proper data-flow analysis: RefCouting the variables 
> on the ctfe-stack could also be a solution.
I presume by "store state" you mean persisting objects beyond the 
bounds of a single CTFE invocation? My first inclination here 
would simply be to make all allocations from a new arena each 
time CTFE is entered (can also re-use memory from prior runs for 
that), do a deep-copy of the result (converting it to full AST 
nodes, etc.), and then drop the entire arena. But probably you 
have thought of (and discarded) this already.
  — David
    
    
More information about the Digitalmars-d-announce
mailing list