Ref counting for CTFE?

[Steven Schveighoffer via Digitalmars-d]

On Thu, 29 May 2014 13:07:17 -0400, safety0ff <safety0ff.dev at gmail.com>  
wrote:

> On Thursday, 29 May 2014 at 16:13:40 UTC, Ary Borenszweig wrote:
>>
>> If you add reference counting or a GC to the compiler, it will make  
>> those large projects compile, but it will inevitably be slower than  
>> now. That's why Walter disabled GC completely in the compiler (turning  
>> it on made the compiler really slow).
>
> AFAIK, he was talking about a whole compiler GC and not a CTFE only  
> GC/RC.
> AFAIK, before the data structures created by CTFE join the AST, they get  
> "scrubbed" which could help us implement a self-contained memory  
> managing strategy for CTFE.

If by "he" you mean me, I was talking only about CTFE, not the whole  
compiler.

In general, any data the compiler generates while actually compiling is  
stored for later reference. Using a GC is not going to help, because the  
compiler doesn't generally create much garbage.

But CTFE is full of code that expects to have a GC running, e.g. string  
concatenation for mixins, etc. Not only that, CTFE functions are generally  
run under the same (or even more strict) rules as strong-pure functions.  
It would be entirely conceivable to just throw away all memory it  
allocates except for the return value. But I don't know how that would  
fare.

But it does REALLY stupid things with memory management within CTFE  
functions. I think this is where RC would help. That bug you referred to  
doesn't even use something that would normally allocate in normal code!

-Steve