Library Development: What to finish/flesh out?

[dsimcha]

== Quote from Sean Kelly (sean at invisibleduck.org)'s article
> On Mar 17, 2011, at 11:56 PM, Don wrote:
> > dsimcha wrote:
> >> I've accumulated a bunch of little libraries via various evening and
> weekend
> >> hacking projects over the past year or so, in various states of
> completion.
> >> Most are things I'm at least half-considering for Phobos, though some
> belong
> >> as third-party libs.  I definitely don't have time to finish/flesh
> out all of
> >> them anytime soon, so I've decided to ask the community what to
> prioritize.
> >> Below is a summary of everything I've been working on, with its
> current level
> >> of completion.  Please let me know the following:
> >
> >> 3.  TempAlloc:  A memory allocator based on a thread-local segmented
> stack,
> >> useful for allocating large temporary buffers in things like numerics
> code.
> >> Also comes with a hash table, hash set and AVL tree optimized for
> this
> >> allocation scheme.  The advantages over plain old stack allocation
> are that
> >> it's independent of function calls (meaning you can return pointers
> to
> >> TempAlloc-allocated memory from a function, etc.) and it's segmented,
> meaning
> >> you can allocate huge buffers w/o risking stack overflow.  Its main
> weakness
> >> is that this stack is not scanned by the GC, meaning that you can't
> store the
> >> only reference to a GC-allocated piece of memory here.  However, in
> practice
> >> large arrays of primitives are an extremely common case in
> >> performance-critical code.  I find this module immensely useful in
> dstats and
> >> Lars Kyllingstad uses it in SciD.  Getting it into Phobos would make
> it easy
> >> for other scientific/numerics code to use it.  Completion state:
> Working and
> >> used.  Needs a litte cleanup and documentation.  (Phobos candidate)
> >
> > This is #1. Far and away. Belongs in druntime.
> Stuff like this is why core.memory isn't called core.gc.

BTW, the TempAlloc module also includes a hash table, hash set and AVL tree that
are specifically optimized for TempAlloc.  Should these be included in the
submission?  The disadvantages I see here is that they are less generally useful
(possibly too high level for druntime) and that they will make the review take a
heck of a lot longer.