RFC: moving forward with @nogc Phobos

[Johannes Pfau via Digitalmars-d]

Am Mon, 29 Sep 2014 15:11:26 -0700
schrieb Andrei Alexandrescu <SeeWebsiteForEmail at erdani.org>:

> On 9/29/14, 10:25 AM, Jacob Carlborg wrote:
> > How does allocators fit in this? Will it be an additional argument
> > to the function. Or a separate stack that one can push and pop
> > allocators to?
> 
> There would be one allocator per thread (changeable) deferring to a 
> global interlocked allocator. Most algorithms would just use whatever 
> allocator is installed.
> 
> I know the notion of a thread-local and then global allocator is
> liable to cause some an apoplexy attack. But it's time to model
> things as they are - memory is a global resource and it ought to be
> treated as such. No need to pass allocators around except for special
> cases.
> 
> 
> Andrei
> 

> No need to pass allocators around except for special
> cases.

So you propose RC + global/thread local allocators as the solution for
all memory related problems as 'memory management is not allocation'.
And you claim that using output ranges / providing buffers / allocators
is not an option because it only works in some special cases?

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.