GC for pure functions -- implementation ideas

[bearophile]

Don:

> But it seems to me that a dedicated GC for pure functions has enormous 
> unexplored potential, and might be relatively easy to implement.

- In D we have not even started to exploit the full potential of purity and pure functions.
- In D reducing the work of the normal GC is a very good thing (because of problems caused by not moving GC, its not precise nature, its not advanced implementation, and because D is a complex system language).
- CommonLisp programmers and designers know that's it's good to give some hints to the the GC. Optional information that help the GC do its work more efficiently. The D1 "scope" attribute for class allocations was a not well designed&implemented example of this.


> (Note that the compiler can determine if a function makes any 
> memory allocations, simply by inspecting its body -- it isn't any more 
> difficult than checking if it is nothrow).

Time ago I have suggested a @noheap that makes sure a function tree doesn't allocate memory. 
What you say makes me think that here user code may just desire to know what the compiler knows: a __traits that given a function name returns a true if the function performs heap allocation.


> With no changes required to the 
> language, and not even any changes required to existing code.

Phobos and other many small things (D too, like some form to express conditional purity, etc) need to change to allow D programmers to use purity more widely in their programs. This in turn will make your pure GC more and more useful.

Bye,
bearophile