Regions and Heaps and Reaps, Oh my (Was: Safety, undefined behavior, @safe, @trusted )

[dsimcha]

== Quote from Andrei Alexandrescu (SeeWebsiteForEmail at erdani.org)'s article
> dsimcha wrote:
> > == Quote from Andrei Alexandrescu (SeeWebsiteForEmail at erdani.org)'s article
> >> Well I'm thinking that often when you use a region, the memory
> >> consumption is not really large. If it's really large, then you may be
> >> better off just using the GC because it means you do a lot of stuff. But
> >> I'm sure I'm ignoring a few important applications.
> >> Andrei
> >
> > By not really large, how big are we talking?  Less than a few 10s of KB?  If so, I
> > think just having the whole thing scanned would be feasible.
> Honest, I don't know. Only real-life usage might tell. At any rate, a
> few 10s of KBs would definitely work for many of my own applications.
> Andrei

Ok, now we're getting somewhere.  I guess if enough ppl find a few 10s of k
useful, we could just make GC scanning and block size configurable.  Maybe through
some static if's we could make it only @trusted if it's scanned by the GC.  I'm
hoping to make a region template that can go into Phobos, and, in some
instantiation, can satisfy just about everyone, and then make TempAlloc simply an
instantiation of this template for my own personal use.  Here are some questions
about how this should work:

1.  What should happen if you try to allocate more space than you have in the
region?  Should it silently fall back to heap allocation?  Should it throw an
exception?  Should it return null?  Should it silently allocate another region block?

2.  Should the region also allow freeing memory in last in, first out order,
behaving somewhat as a stack?  The advantage to doing so would be to increase
flexibility.  The downside is that you would have to do a little bookkeeping
internally, and the overhead of this might be too high for the use case of lots of
tiny allocations.  Maybe this should also be a policy.  Also, if it's a region + a
stack, can we call it a "rack"?

3.  Should it be designed as a normal object (more flexible but less convenient)
or a thread-local singleton that lazily initializes itself and is just there, kind
of like malloc (more convenient but less flexible)?

4.  Any other generic comments on how this should be designed?