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
