RFC: moving forward with @nogc Phobos

[Johannes Pfau via Digitalmars-d]

Am Tue, 30 Sep 2014 10:47:54 +0000
schrieb "Vladimir Panteleev" <vladimir at thecybershadow.net>:

> On Tuesday, 30 September 2014 at 08:34:26 UTC, Johannes Pfau 
> wrote:
> > What if I don't want automated memory _management_? What if I 
> > want a
> > function to use a stack buffer? Or if I want to free manually?
> >
> > If I want std.string.toStringz to put the result into a 
> > temporary stack
> > buffer your solution doesn't help at all. Passing an ouput 
> > range,
> > allocator or buffer would all solve this.
> 
> I don't understand, why wouldn't you be able to temporarily set 
> the thread-local allocator to use the stack buffer, and restore 
> it once done?

That's possible but insanely dangerous in case you forget to reset the
thread allocator. Also storing stack pointers in global state (even
thread-local) is dangerous, for example interaction with fibers could
lead to bugs, etc. (What if I set the allocator to a stack allocator
and call a function which yields from a Fiber?).

You also loose all possibilities to use 'scope' or a similar mechanism
to prevent escaping a stack pointer. 

Also a stack buffer is not a complete allocator, but in some
cases like toStringz it works even better than allocators (less
overhead as you know the required buffer size before calling toStringz
and there's only one allocation)

And it is a hack. Of course you can provide a wrapper which does
oldAlloc = threadLocalAllocator;
threadLocalAllocator = stackbuf;
func();
scope(exit)
    threadLocalAllocator = oldAlloc;

But how could anybody think this is good API design? I think I'd rather
fork the required Phobos functions instead of using such a wrapper.