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
> >> dsimcha wrote:
> >>> == Quote from Andrei Alexandrescu (SeeWebsiteForEmail at erdani.org)'s article
> >>>> Steven Schveighoffer wrote:
> >>>>> On Thu, 05 Nov 2009 16:30:42 -0500, Andrei Alexandrescu
> >>>>> <SeeWebsiteForEmail at erdani.org> wrote:
> >>>>>
> >>>>>>>  Most of the usages are like this:
> >>>>>>>  ubyte[1024] buffer;
> >>>>>>> functionThatNeedsBufferSpace(buffer);
> >>>>>>>  where functionThatNeedsBufferSpace takes a ubyte[], thereby taking
> >>>>>>> an address of the local data.
> >>>>>>>  So it's not explicit address taking, but it's the same thing under
> >>>>>>> the hood.  There always exists the potential for the stack reference
> >>>>>>> to escape.
> >>>>>> I see, thank you. I am confident that a trusted reap could be
> >>>>>> implemented in the standard library. (google reap)
> >>>>> I did.  Couldn't find anything.
> >>>> Damn acronyms, sorry. Better results: reap memory allocation
> >>>> ftp://ftp.cs.utexas.edu/pub/emery/papers/reconsidering-custom.pdf
> >>>> Andrei
> >>> Ok, I understand the basic principle of a reap, but if it's going to convert
to a
> >>> heap when you try to delete something, why not just improve the standard GC
heap,
> >>> i.e. by making per-thread heaps?  If you're not going to delete stuff, why not
> >>> just use a regular old region or stack (not necessarily the call stack, but a
> >>> stack of some kind)?
> >> Perhaps a region could also be defined as a @trusted facility! So much
> >> good stuff to do, so little time...
> >> Andrei
> >
> > I have my doubts only b/c I've worked on similar things before and the thing that
> > keeps biting me in the @$$ is how to handle the GC.  If you allocate some huge
> > block of memory to parcel out and have it all be scanned by the GC, you're asking
> > for slow scan times and lots of false pointers, thus largely defeating the purpose
> > of the region scheme.
> 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.