DIP 1008 Preliminary Review Round 1

[Jonathan M Davis via Digitalmars-d]

On Saturday, May 20, 2017 12:34:09 PM PDT H. S. Teoh via Digitalmars-d 
wrote:
> On Sat, May 20, 2017 at 07:53:58AM +0000, Stefan Koch via Digitalmars-d 
wrote:
> > On Saturday, 20 May 2017 at 07:02:10 UTC, Walter Bright wrote:
> > > Also, have a GC makes CTFE real nice.
> >
> > Having to implement a GC for newCTFE won't be nice though :o)
> > I agree though being able to allocate memory makes ctfe much more
> > useful then it would otherwise be.
>
> I think we might be able to get away without implementing a GC for
> newCTFE.  All you need is a memory pool allocator, i.e., a
> bump-the-pointer algorithm to a block of memory (or maybe a linked list
> of blocks if we need to make it growable) allocated when you enter CTFE,
> then upon exiting CTFE, copy out the return value(s) and free the entire
> pool.
>
> As long as we don't anticipate CTFE code that requires massive amounts
> of allocation / deallocation before producing a result, this ought to be
> good enough.

Well, from the perspective of ther user's code, there really isn't any
difference. They can allocate memory with new, and the compiler takes care
of managing the memory.

- Jonathan M Davis