GC for pure functions -- implementation ideas

Jonathan M Davis jmdavisProg at gmx.com
Mon Nov 7 20:38:45 PST 2011


On Monday, November 07, 2011 23:28:28 Robert Jacques wrote:
> On Fri, 15 Apr 2011 16:12:34 -0400, Don <nospam at nospam.com> wrote:
> [snip]
> 
> > In reality, things are going to be a bit more complicated than this. But
> > it seems to me that conceptually, something like this could still stay
> > fairly simple and be very, very fast. With no changes required to the
> > language, and not even any changes required to existing code.
> I really like this general concept (It feels a lot like young/old
> generational collecting, but without the overhead), both for non-leaky
> pure functions and ctfe.
> 
> On a side note, core.memory.gc is not currently marked pure and/or
> nothrow, so Appender / containers which use the low level GC commands for
> performance can't be used in pure/nothrow code. I'm not sure how to fix
> this, as it would essentially have to violate the type system in a major
> way. It's one more thing to think about with regard to purity and the GC.

The fact that Appender isn't pure is a huge blow to purity. At least with 
nothrow, you can wrap it in a try-catch block, but there is no such option for 
pure. You could probably cast a function pointer to pure if you had to, but 
that is at least stretching the type system if not outright breaking it - 
though if you're _certain_ that the function is effectively pure, then it 
should be fine. Regardless, a solution really should be found to the issue of 
purity and Appender.

- Jonathan M Davis


More information about the Digitalmars-d mailing list