Hidden allocations (Was: Array literals REALLY should be immutable )

[dsimcha]

== Quote from Denis Koroskin (2korden at gmail.com)'s article
> I strongly believe that "No hidden allocation" policy should be adopted by
> D/Phobos (it is already adopted by Tango with a great success).

I can see the value in this, but two issues:

1.  What counts as a "hidden" allocation?  How non-obvious does it have to be that
something requires an allocation?  If something really has to allocate and it's
not obvious from the nature of the function, is it enough to just document it?

2.  How do you really design high-level library functions if they're not allowed
to allocate memory?  If you require the user to provide all kinds of details about
where the memory they use comes from then you lose some of the high level-ness and
make it seem more like an ugly C API that doesn't "just work" and requires
attention to the irrelevant the 90% of the time that you don't care about an extra
allocation.  The solution I personally use in my dstats lib, which works pretty
well in the limited case of arrays of primitives, but might not generalize, is:

    a.  For stuff that returns an array, the last argument to the function is an
optional buffer.  If it is provided and is big enough, the results are returned in
it.  If it is not provided or is too small, a new one is allocated.

    b.  For temporary buffers used within a function, I use a thread-local second
stack  (TempAlloc).  While this is not **guaranteed** never to result in an
allocation (if we're out of space in our current chunk of memory, a new one will
be allocated), it very seldom does and only when the only alternative would be to
crash, throw an exception, etc.