TempAlloc Overhaul

[Andrei Alexandrescu]

On 6/17/11 1:28 PM, David Nadlinger wrote:
> On 6/17/11 7:59 PM, Jose Armando Garcia wrote:
>> Hmm. I don't know. Maybe we can create an internal package
>> (std.internal) that std modules can use in their implementation. The
>> daring programmer can also use if they dig around but maybe we
>> shouldn't put the gun on the kitchen counter. Modules in std.internal
>> should be ddoc but they are not linked from
>> d-programming-language.org.
>
> I don't quite see how std.internal relates to the TempAlloc proposal.
> std.internal is a namespace for modules that are, well, Phobos-internal,
> and not part of the public API – hence, they are not publicly documented
> at d-programming-language.org as well. No guarantees about API
> stability, etc. are made, they should never be used from outside Phobos.
>
> On the other hand, TempAlloc is generally useful if you are writing
> performance-sensitive code. It is only a »hack« insofar as it allows you
> to break some guarantees in order to be able to gain performance, not
> because it has an unstable API or something like that. Obviously, you
> _can_ shoot yourself in the foot with it, but there isn't quite a way
> this could be avoided. One could even argue that for »unsafe« things,
> having well documented and tested library artifacts is even more
> important than for basic, »safe« things.
>
> David

The one thing std.tempalloc should do is make it very clear it is 
unsafe, with the expected liabilities. I think the current version is 
very coy about it.

Andrei